Standard C Libraries Application Programmming Interface to System-Calls
Important File-I/O Functions int open( char *pathname, int flags, … ); int read( int fd, void *buf, size_t count ); int write( int fd, void *buf, size_t count ); int lseek( int fd, loff_t offset, int whence ); int close( int fd );
UNIX ‘man’ pages • A convenient online guide to prototypes and semantics of the C linrary functions • Example of usage: $ man 2 open
The ‘open’ function • • • #include <fcntl. h> int open( char *pathname, int flags, … ); Converts a pathname to a file-descriptor File-descriptor is a nonnegative integer Used as a file-ID in subsequent functions ‘flags’ is a symbolic constant: O_RDONLY, O_WRONLY, O_RDWR
The ‘close’ function • • #include <unistd. h> int close( int fd ); Breaks link between file and file-descriptor Returns 0 on success, or -1 if an error
The ‘write’ function • • #include <unistd. h> int write( int fd, void *buf, size_t count ); Attempts to write up to ‘count’ bytes Bytes are taken from ‘buf’ memory-buffer Returns the number of bytes written Or returns -1 if some error occurred Return-value 0 means no data was written
The ‘read’ function • • #include <unistd. h> int read( int fd, void *buf, size_t count ); Attempts to read up to ‘count’ bytes Bytes are placed in ‘buf’ memory-buffer Returns the number of bytes read Or returns -1 if some error occurred Return-value 0 means ‘end-of-file’
Notes on ‘read()’ and ‘write()’ • These functions have (as a “side-effect”) the advancement of a file-pointer variable • They return a negative function-value of -1 if an error occurs, indicating that no actual data could be transferred; otherwise, they return the number of bytes read or written • The ‘read()’ function normally does not return 0, unless ‘end-of-file’ is reached
The ‘lseek’ function • #include <unistd. h> • off_t lseek( int fd, off_t offset, int whence ); • Modifies the file-pointer variable, based on the value of whence: enum { SEEK_SET, SEEK_CUR, SEEK_END }; • Returns the new value of the file-pointer (or returns -1 if any error occurred)
Getting the size of a file • For normal files, your application can find out how many bytes belong to a file using the ‘lseek()’ function: int filesize = lseek( fd, 0, SEEK_END ); • But afterward you need to ‘rewind’ the file if you want to read its data: lseek( fd, 0, SEEK_SET );
What about ‘pseudo’ files? • You can use standard library functions to open, read, and close a ‘/proc’ pseudo-file • You can use ‘lseek’ (except SEEK_END) • An example is our ‘howfast. cpp’ program • It measures how fast ‘jiffies’ increments • It opens, reads, and closes ‘/proc/jiffies’ • And it also uses ‘lseek’ (to rewind this file)
How these system-calls work C Runtime Library Operating System Kernel Application Program Module ‘methods’ User-space Kernel-space
Special ‘device’ files • UNIX systems treat hardware-devices as special files, so that familiar functions can be used by application programmers to access these devices (open, read, close) • But a System Administrator has to create these device-files (in the ‘/dev’ directory) • There are two categories of device files: ‘character’ devices, and ‘block’ devices
The ‘mknod’ command • To create the device-node for a character device, an Administrator executes ‘mknod’ root# mknod /dev/scull c 48 0 • Here ‘/dev/scull’ is the file’s pathname, ‘c’ indicates that it’s a character-mode device, 48 is its (unique) ‘major’ ID-number, and 0 is its (unique) ‘minor’ ID-number • Default access-privileges: r w - r - • Can be modified using ‘chmod’ command
What’s new in 2. 6? • Earlier Linux kernels stored the ‘/dev’ files on the hard disk (so they were persistent) • The 2. 6 kernel stores them in a ram-disk • So they ‘disappear’ during every shutdown • You need ‘root’ privileges to re-build them! • (Fortunately this step can be automated if device-nodes are in ‘/etc/udev/devices’ )
A useful device-driver • We can create a character-mode driver for the processor’s physical memory (i. e. ram) • (Our machines have 1 -GB of physical ram) • But another device-file is named ‘/dev/ram’ so ours will be: ‘/dev/dram’ (dynamic ram) • We’ve picked 253 as its ‘major’ ID-number • Our Sys. Admin setup a device-node using: root# mknod /dev/dram c 253 0
Device knowledge • Before you can write a device-driver, you must understand how the hardware works • Usually this means you need to obtain the programmer manual (from manufacturer) • Nowdays this can often be an obstacle • But some equipment is standardized, or is well understood (because of its simplicity)
1 -GB RAM has ‘zones’ ZONE_HIGH 1024 -MB (= 1 GB) 128 -MB ZONE_NORMAL ZONE_LOW 16 -MB
Legacy DMA • Various older devices rely on the PC/AT’s DMA controller to perform data-transfers • This chip could only use 24 -bit addresses • Only the lowest 16 -megabytes of physical memory are ‘visible’ to these devices: 224 = 0 x 01000000 (16 -megabytes) • Linux tries to conserve its use of memory from this ZONE_LOW region for anything except DMA (so it will available if needed)
‘HIGH’ memory • Linux traditionally tried to ‘map’ as much physical memory as possible into virtual addresses allocated to the kernel-space • Before the days when systems had 1 -GB or more of installed memory, Linux could linearly map ALL of the physical memory into the 1 -GB kernel-region: 0 x. C 0000000 – 0 x. FFFF • But with 1 GB there’s not enough room!
The 896 -MB limit HIGH MEMORY 896 -MB not-mapped DRAM (1 GB) Kernel space (1 GB) Physical address-space linearly mapped A special pair of kernel-functions named ‘kmap()’ and ‘kunmap()’ can be called by device-drivers to temporarily map pages of physical memory into ‘vacant’ areas within the kernel’s virtual address-space User space (3 GB) Virtual address-space
‘copy_to_user()’ • With kernel 2. 6, it is possible to configure the user-space versus kernel-space ‘split’ so that nearly 4 GB of physical memory is always linearly mapped into kernel-space • The configuration-option is CONFIG_4 GB • With this option enabled, the user-space and kernel-space use two different maps • So device-drivers need a special function to transfer kernel-data to a user’s buffer
Driver-module structure • We will need three kernel header-files: – #include <linux/module> // for printk(), register_chrdev(), unregister_chrdev() – #include <linux/highmem. h> // for kmap(), kunmap(), and ‘num_physpages’ – #include <asm/uaccess. h> // for copy_to_user()
Our ‘dram_size’ global • Our ‘init_module()’ function will compute the size of the installed physical memory • It will be stored in a global variable, so it can be accessed by our driver ‘methods’ • It is computed from a kernel global using the PAGE_SIZE constant (=4096 for x 86) dram_size = num_physpages * PAGE_SIZE
‘major’ ID-number • Our ‘major’ device ID-number is needed when we ‘register’ our device-driver with the kernel (during initialization) and later when we ‘unregister’ our device-driver (during the cleanup procedure): int my_major = 253; // static ID-assignment
Our ‘file_operations’ • Our ‘dram’ device-driver does not need to implement special ‘methods’ for doing the ‘open()’, ‘write()’, or ‘release()’ operations (the kernel ‘default’ operations will suffice) • But we DO need to implement ‘read()’ and ‘llseek()’ methods • Our ‘llseek()’ code here is very standard • But ‘read()’ is specially crafted for DRAM
Using our driver • We have provided a development tool on the class website (named ‘fileview. cpp’) which can be used to display the contents of files (including device-files) • The data is shown in hex and ascii formats • The arrow-keys can be used for navigation • The enter-key allows an offset to be typed • Keys ‘b’, ‘w’, ‘d’ and ‘q’ adjust data-widths
In-class exercise #1 • Install the ‘dram. ko’ device-driver module; then use ‘fileview’ to browse the contents of the processor’s physical memory: $ fileview /dev/dram
Control Register CR 3 • Register CR 3 holds the physical-address of the system’s current ‘page-directory’ • The page-directory is an array of 1024 entries, showing how ‘virtual addresses’ are currently ‘mapped’ to physical pages • With ‘fileview’ you can find and examine this important kernel data-structure – but you must know the value in register CR 3
In-class exercise #2 • Use the ‘newinfo’ wizard to quickly create a pseudo-file (named ‘/proc/cr 3’) that will allow user-programs to obtain the current value of the Pentium’s CR 3 register • Write a tool (named ‘seepgdir. cpp’) that will read ‘/proc/cr 3’ to get the address of the page-directory, then read it from the ‘/dev/dram’ device and print it onscreen
Скачать презентацию Standard C Libraries Application Programmming Interface to System-Calls
c72e91f3de6da6d1030d99a4c85de422.ppt