Microsoft PowerPoint - Chapter7-DriverDevices.ppt

Transcription

1 Chapter 7 Device Drivers and Software Interface Design Professor Ching-Lung Su kevinsu@yuntech.edu.tw NYUST/EL

2 P-2/80 Outline 7.1 Introduction to Device Driver 7.2 Linux Driver 7.3 Efficiency Optimization of the Driver

3 P-3/ Introduction to Device Driver 7.1 Introduction to Device Driver 7.2 Linux Driver 7.3 Efficiency Optimization of the Driver

4 7.1 Introduction to Device Driver Introduction to Linux Device Driver Introduction to WinCE Device Driver P-4/80

5 7.1 Introduction to Device Driver A Device Driver has Three Sides: The Rest of the Kernel Side The Hardware Side The User Side P-5/80

6 P-6/ Introduction to Linux Device Driver Splitting the Kernel Kernel Subsystems Features Implemented Sofware Support Hardware

7 7.1 Introduction to Linux Device Driver Process management The kernel is in charge of creating and destroying processes and handling their connection to the outside world (input and output). Communication among different processes (through signals, pipes, or inter-process communication primitives) is basic to the overall system functionality and is also handled by the kernel. The scheduler which controls how processes share the CPU, is part of process management. P-7/80

8 P-8/ Introduction to Linux Device Driver The kernel s process management activity implements the abstraction of several processes on top of a single CPU or a few of them.

9 7.1 Introduction to Linux Device Driver Memory management The computer s memory is a major resource, and the policy used to deal with it is a critical one for system performance. The kernel builds up a virtual addressing space for any and all processes on top of the limited available resources. The different parts of the kernel interact with the memorymanagement subsystem through a set of function calls, ranging from the simple malloc/free pair to much more complex functionalities. P-9/80

10 7.1 Introduction to Linux Device Driver Filesystems Unix is heavily based on the filesystem concept. Almost everything in Unix can be treated as a file. The kernel builds a structured filesystem on top of unstructured hardware, and the resulting file abstraction is heavily used throughout the whole system. Linux supports multiple filesystem types, that is different ways of organizing data on the physical medium. For example, disks may be formatted with the Linux-standard ext3 filesystem, the commonly used FAT filesystem or several others. P-10/80

11 7.1 Introduction to Linux Device Driver Device control Almost every system operation eventually maps to a physical device. With the exception of the processor, memory, and a very few other entities, any and all device control operations are performed by code that is specific to the device being addressed. That code is called a device driver. The kernel must have embedded in it a device driver for every peripheral present on a system, from the hard drive to the keyboard and the tape drive. This aspect of the kernel s functions is our primary interest in this book. P-11/80

12 7.1 Introduction to Linux Device Driver Networking Networking must be managed by the operating system, because most network operations are not specific to a process: incoming packets are asynchronous events. The packets must be collected, identified, and dispatched before a process takes care of them. The system is in charge of delivering data packets across program and network interfaces, and it must control the execution of programs according to their network activity. All the routing and address resolution issues are implemented within the kernel. P-12/80

13 7.1 Introduction to Linux Device Driver Classes of Devices and Modules The three classes are: Character device Block device Network interface P-13/80

14 7.1 Introduction to Linux Device Driver Character device Can be accessed as a stream of bytes (like a file). A char driver is in charge of implementing this behavior. Implements at least the Open Close Read Write system calls. The examples of char devices are The text console (/dev/console) The serial ports (/dev/ttys0 and friends) P-14/80

15 7.1 Introduction to Linux Device Driver Accessed by means of file system nodes, such as /dev/tty1 /dev/lp0 The only relevant difference between a char device and a regular file is that you can always move back and forth in the regular file, whereas most char devices are just data channels, which you can only access sequentially. Look like data areas, and you can move back and forth in them. Applies to frame grabbers, where the applications can access the whole acquired image using mmap or lseek. P-15/80

16 7.1 Introduction to Linux Device Driver Block device Accessed by filesystem nodes in the /dev directory. Can host a filesystem. Can only handle I/O operations that transfer one or more whole blocks, which are usually 512 bytes (or a larger power of two) bytes in length. Allows the application to read and write a block device like a char device it permits the transfer of any number of bytes at a time. Block and char devices differ only in the way data is managed internally by the kernel, and thus in the kernel/driver software interface. P-16/80

17 7.1 Introduction to Linux Device Driver Like a char device, each block device is accessed through a filesystem node, and the difference between them is transparent to the user. Block drivers have a completely different interface to the kernel than char drivers. P-17/80

18 7.1 Introduction to Linux Device Driver Network interface Can exchange data with other hosts. In charge of sending and receiving data packets, driven by the network subsystem of the kernel, without knowing how individual transactions map to the actual packets being transmitted. Many network connections (especially those using TCP) are stream-oriented, but network devices are designed around the transmission and receipt of packets. A network driver knows nothing about in individual connections. Only handles packets. P-18/80

19 7.1 Introduction to Linux Device Driver The Unix way to provide access to interfaces is still by assigning a unique name to them (such as eth0), but that name doesn t have a corresponding entry in the filesystem. Communication between the kernel and a network device driver is completely different from that used with char and block drivers. Instead of read and write, the kernel calls functions related to packet transmission. P-19/80

20 P-20/ Introduction to WinCE Device Driver WinCE Device Driver Architecture

21 7.1 Introduction to WinCE Device Driver GWES: The Graphics, Windowing and Event Subsystem In CE can have two layers in a device driver MDD (Model Device Driver) The top level that interfaces to the OS using Device Driver Interface (DDI) Idea is that you should not need to change the MDD layer for minor hardware changes. PDD (Physical Device Driver) The low level that interfaces to the hardware and talks to MDD using Device Driver Service-Provider Interface (DDSI). P-21/80

22 7.1 Introduction to WinCE Device Driver Supports two internal device driver models Native Device Driver Stream Interface Device Driver P-22/80

23 7.1 Introduction to WinCE Device Driver Native Device Driver Custom interface for low level built-in hardware such as keyboards and displays. Stream Interface Driver Generic file type device driver. Required entry points all must be implemented XXX_Init / XXX_DeInit XXX_PowerUp / XXX_PowerDown XXX_Open / XXX_Close XXX_Read / XXX_Write XXX_Seek XXX_IOControl P-23/80

24 7.1 Introduction to WinCE Device Driver Detection function Detection ordering Debug messages DEBUGMSG (true, (TEXT("DRVR453: DetectCard returning %s \r\n"),devkey)); Device side interface The driver will use Card Services functions to interact with the PC-Card hardware CardRegisterClient / CardDeregisterClient CardRequestWindow / CardReleaseWindow CardMapWindow CardRequestIRQ /CardReleaseIRQ P-24/80

25 P-25/ Introduction to WinCE Device Driver Application side interface Your application software will interact with your PC-Card hardware through a file object completely decoupling it from the hardware. CreateFile Used by application to create a file object, results in call toxxx_open for device type specified (i.e. if COM1: is name,com_open is called on the active driver for COM1) Returns handleto file object used by other functions.

26 7.1 Introduction to WinCE Device Driver CloseHandle Closes file object, results in call to XXX_Close. WriteFile Send data to file object, results in call to XXX_Write,passes handle back. ReadFile Gets data from file object, results in call to XXX_Read, passes handle back. DeviceIoControl Used to pass commands to device, results in call to XXX_IOControl, passes handle back. P-26/80

27 P-27/ Introduction to WinCE Device Driver Note that the actual effect of these functions is based on how you write your driver! You can write a stub driver that will allow you to test your application software without actually accessing hardware.

28 P-28/ Linux Driver 7.1 Introduction to Device Driver 7.2 Linux Driver 7.3 Efficiency Optimization of the Driver

29 7.2 Linux Driver Linux Kernel Modules Char Device Driver P-29/80

30 7.2 Linux Kernel Modules The printk function is defined in the Linux kernel and behaves similarly to the standard C library function printf. Example : #define MODULE #include <linux/module.h> int init_module(void) { printk("<1>hello, world\n"); return 0; } void cleanup_module(void) { printk("<1>goodbye cruel world\n"); } P-30/80

31 7.2 Linux Kernel Modules You can test the module by calling insmod and rmmod, as shown in the screen. Note that only the superuser can load and unload a module. Example : root# gcc -c hello.c root# insmod./hello.o Hello, world root# rmmod hello Goodbye cruel world P-31/80

32 7.2 Linux Kernel Modules modprobe and insmode modprobe functions in much the same way as insmod, but it also loads any other modules that are required by the module you want to load. One modprobe command can sometimes replace several invocations of insmod (although you ll still need insmod when loading your own modules from the current directory,because modprobe only looks in the tree of installed modules /lib/modules/ ). insmod The module can call printk because, after insmod has loaded it, the module is linked to the kernel and can access the kernel s public symbols. P-32/80

33 7.2 Linux Kernel Modules The public symbol table can be read in text form from the file /proc/ksyms (assuming, of course, that your kernel has support for the /proc filesystem which it really should). When a module is loaded, any symbol exported by the module becomes part of the kernel symbol table, and you can see it appear in /proc/ksyms or in the output of the ksyms command. New modules can use symbols exported by your module, and you can stack new modules on top of other modules. P-33/80

34 7.2 Linux Kernel Modules An application performs a single task from beginning to end, a module registers itself in order to serve future requests, and its main function terminates immediately. The task of the function init_module (the module s entry point) is to prepar e for later invocation of the module s functions; it s as though the module were saying, Here I am, and this is what I can do. P-34/80

35 7.2 Linux Kernel Modules An application can call functions it doesn t define: the linking stage resolves external references using the appropriate library of functions. printf is one of those callable functions and is defined in libc. A module is linked only to the kernel, and the only functions it can call are the ones exported by the kernel; there are no libraries to link to. Because no library is linked to modules, source files should never include the usual header files. Only functions that are actually part of the kernel itself may be used in kernel modules. P-35/80

36 P-36/ Linux Kernel Modules Linux driver : Linking a module to the kernel

37 7.2 Linux Kernel Modules Many of the declarations in the kernel header files are relevant only to the kernel itself and should not be seen by user-space applications. These declarations are therefore protected by #ifdef KERNEL blocks. Driver, like other kernel code, will need to be compiled with the KERNEL preprocessor symbol defined. Example : #ifdef kernel #define cpu arm #endif P-37/80

38 P-38/ Linux Kernel Modules Error Handling in init_module If any errors occur when you register utilities, you must undo any registration activities performed before the failure. Linux doesn t keep a per-module registry of facilities that have been registered, so the module must back out of everything itself if init_module fails at some point. The following sample code behaves correctly if initialization fails at any point.

39 7.2 Linux Kernel Modules Example : int init_module(void) { int err; err = register_this(ptr1, skull ); if(err) goto fail_this; err = register_that(ptr2, skull ); if(err) goto fail_that; err = register_those(ptr3, skull ); if(err) goto fail_those; return 0; fail_those : unregister_that(ptr2, skull ); fail_that: unregister_this(ptr, skull ); fail_this : return err; } P-39/80

40 7.2 Linux Kernel Modules The return value of init_module, err, is an error code. In the Linux kernel, error codes are negative numbers belonging to the set defined in <linux/errno.h>. If you want to generate your own error codes instead of returning what you get from other functions, you should include <linux/errno.h> in order to use symbolic values such as -ENODEV, -ENOMEM. P-40/80

41 7.2 Linux Kernel Modules Cleanup_module must undo any registration performed by init_module, and it is customary (but not mandatory) to unregister facilities in the reverse order used to register them. Example : void cleanup_module(void) { unregister_those(ptr3, "skull"); unregister_that(ptr2, "skull"); unregister_this(ptr1, "skull"); return; } P-41/80

42 7.2 Linux Kernel Modules The cleanup function, then, must check the status of each item before undoing its registration. In its simplest form, the code looks like the following : Example : struct something *item1; struct somethingelse *item2; int stuff_ok; void cleanup_module(void) { if (item1) release_thing(item1); if (item2) release_thing2(item2); if (stuff_ok) unregister_stuff(); return; } P-42/80

43 7.2 Linux Kernel Modules Example (cont.): int init_module(void) { int err = -ENOMEM; item1 = allocate_thing(arguments); item2 = allocate_thing2(arguments2); if (!item2!item2) goto fail; err = register_stuff(item1, item2); if (!err) stuff_ok = 1; else goto fail; return 0; /* success */ fail: cleanup_module(); returnerr; } P-43/80

44 7.2 Linux Kernel Modules To unload a module Use the rmmod command. Its task is much simpler than loading, since no linking has to be performed. The command invokes the delete_module system call, which calls cleanup_module in the module itself if the usage count is zero or returns an error otherwise. The cleanup_module implementation is in charge of unregistering every item that was register ed by the module. Only the exported symbols are removed automatically. P-44/80

45 7.2 Linux Kernel Modules The programming interface used to access the I/O registry is made up of threefunctions: Int check_region(unsigned long start, unsigned long len); Struct resource *request_region(unsigned long start,unsigned long len, char *name); Void release_region(unsigned long start, unsigned long len); P-45/80

46 7.2 Linux Kernel Modules check_region may be called to see if a range of ports is available for allocation; itretur ns a negative error code (such as -EBUSY or - EINVAL) if the answer is no. request_region will actually allocate the port range, returning a non-null pointer value if the allocation succeeds. release_region is to release the ports when it is done with them. P-46/80

47 7.2 Char Device Driver Major and Minor Numbers Special files for char drivers are identified by a "c" in the first column of the output of ls -l. Block devices appear in /dev as well, but they are identified by a "b." The minor number is used only by the driver specified by the major number. It is common for a driver to control several devices; the minor number provides a way for the driver to differentiate among them. P-47/80

48 7.2 Char Device Driver crw-rw-rw- 1 root root 1, 3 Feb null crw root root 10, 1 Feb psaux crw rubini tty 4, 1 Aug 16 22:22 tty1 crw-rw-rw- 1 root dialout 4, 64 Jun 30 11:19 ttys0 crw-rw-rw- 1 root dialout 4, 65 Aug 16 00:00 ttys1 crw root sys 7, 1 Feb vcs1 crw root sys 7, 129 Feb vcsa1 crw-rw-rw- 1 root root 1, 5 Feb zero Major Device Number Minor Device Number P-48/80

49 7.2 Char Device Driver Major and Minor Numbers The minor number is used only by the driver specified by the major number. It is common for a driver to control several devices (as shown in the listing). The minor number provides a way for the driver to differentiate among them. The kernel don t use it, and merely pass it along to the driver. For example,/dev/null and /dev/zero are both managed by driver 1. P-49/80

50 7.2 Char Device Driver Adding a new driver to the system means assigning a major number to it. The assignment should be made at driver (module) initialization by calling the following function, defined in <linux/fs.h>: Example : int register_chrdev(unsigned int major, const char *name, struct file_operations *fops); The return value indicates success or failure of the operation. A negative return code signals an error. A 0 or positive return code reports successful completion. The 2.0 kernel supported 128 devices; 2.2 and 2.4 increased that number to 256 (while reserving the values 0 and 255 for future uses). Minor numbers, too. P-50/80

51 7.2 Char Device Driver The major argument is the major number being requested. Name is the name of your device. It will appear in /proc/devices. Fops is the pointer to an array of function pointers, used to invoke your driver s entry points. P-51/80

52 7.2 Char Device Driver Give programs a name by which they can request your driver. A name must be inserted into the /dev directory and associated with your driver s major and minor numbers. The command takes three arguments in addition to the name of the file being created. For example, the command mknod /dev/scull0 c Creates a char device (c) whose major number is 254 and whose minor number is 0. P-52/80

53 7.2 Char Device Driver The information about kdev_t is confined in <linux/kdev_t.h>, which is mostly comments. The following macros and functions are the operations you can perform on kdev_t: MAJOR (kdev_t dev); Extract the major number from a kdev_t structure. MINOR (kdev_t dev); Extract the minor number. MKDEV (int ma, int mi); Create a kdev_t built from major and minor numbers. P-53/80

54 7.2 Char Device Driver Kdev_t_to_nr (kdev_t dev); Convert a kdev_t type to a number (a dev_t). To_kdev_t(int dev); Convert a number to kdev_t. Note that dev_t is not defined in kernel mode, and therefore int is used. If kdev_t remains hidden, it can change from one kernel version to the next as needed, without requiring changes to everyone s device drivers. P-54/80

55 7.2 Char Device Driver File Operations An open device is identified internally by a file structure, and the kernel uses the file_operations structure to access the driver s functions. The structure, defined in < linux/fs.h >, is an array of function pointers. Each file is associated with its own set of functions (by including a field called f_op that points to a file_operations structure). P-55/80

56 P-56/ Char Device Driver fd Kernel file -> fops Driver file_operations A() B() C() A() B() NULL

57 7.2 Char Device Driver Loff_t (*llseek) (struct file *, loff_t, int); The llseek method is used to change the current read/write position in a file,and the new position is returned as a (positive) return value. The loff_t is a long offset and is at least 64 bits wide even on 32- bit platforms. Ssize_t (*read) (struct file *, char *, size_t, loff_t *); Used to retrieve data from the device. A null pointer in this position causes the read system call to fail with -EINVAL ( Invalid argument ). A non-negative return value represents the number of bytes successfully read. P-57/80

58 7.2 Char Device Driver Ssize_t (*write) (struct file *, const char *, size_t, loff_t *); Sends data to the device. The return value, if non-negative, represents the number of bytes successfully written. Int (*open) (struct inode *, struct file *); Though this is always the first operation performed on the device file. The driver is not requied to declare a corresponding method. If this entry is NULL,opening the device always succeeds, but your driver isn t notified. Int (*release) (struct inode *, struct file *); This operation is invoked when the file structur e is being released. P-58/80

59 7.2 Char Device Driver The scull device driver implements only the most important device methods, and uses the tagged format to declare its file_operations structure Example : struct file_operations scull_fops = { llseek: scull_llseek, read: scull_read, write: scull_write, ioctl: scull_ioctl, open: scull_open, release: scull_release, }; P-59/80

60 7.2 Char Device Driver Read and write methods The read and write methods perform a similar task, that is, copying data from and to application code. Example : ssize_t read(struct file *filp, char *buff, size_t count, loff_t *offp); ssize_t write(struct file *filp, const char *buff, size_t count, loff_t *offp); Filp is the file pointer Count is the size of the requested data transfer. The buff argument points to the user buffer holding the data to be written or the empty buffer where the newly read data should be placed. Offp is a pointer to a long offset type object that indicates the file position the user is accessing. P-60/80

61 7.2 Char Device Driver One big difference between kernel-space addresses and user-space addresses is that memory in user-space can be swapped out. When the kernel accesses a userspace pointer, the associated page may not be present in memory, and a page fault is generated. Cross-space copies are per formed in Linux by special functions, defined in <asm/uaccess.h>. P-61/80

62 7.2 Char Device Driver Although these functions behave like normal memcpy functions, a little extra care must be used when accessing user space from kernel code. Example : unsigned long copy_to_user(void *to, const void *from,unsigned long count); unsigned long copy_from_user(void *to, const void *from,unsigned long count); The role of the two functions is not limited to copying data to and from userspace: they also check whether the user space pointer is valid. P-62/80

63 P-63/ Char Device Driver The arguments to read

64 7.2 Char Device Driver The read Method If the value equals the count argument passed to the read system call, the requested number of bytes has been transferred. If the value is positive, but smaller than count, only part of the data has been transferred. If the value is 0, end-of-file was reached. A negative value means there was an error. The value specifies what the error was, according to <linux/errno.h>. P-64/80

65 P-65/ Efficiency Optimization of the Driver 7.1 Introduction to Device Driver 7.2 Linux Driver 7.3 Efficiency Optimization of the Driver

66 7.3 Efficiency Optimization of the Driver The inline assembler is a powerful new feature allowing the programmer to easily access the full functionality of the ARM instruction set within the C environment. Assembly code can use any C or C++ variable or function name that is in scope, so it is easy to integrate it with your program's C and C++ code. Assembly language serves many purposes, such as improving program speed, reducing memory needs, and controlling hardware. P-66/80

67 7.3 Efficiency Optimization of the Driver The Format of Basic Inline Assembly asm("assembly code"); Example : asm("movl %ecx %eax"); /* moves the contents of ecx to eax */ asm ("movb %bh (%eax)"); /*moves the byte from bh to the memory pointed by eax */ P-67/80

68 7.3 Efficiency Optimization of the Driver If there are more than one instructions, we write one per line in double quotes, and also suffix \n and \t to the instruction. Example : asm ("movl %eax, %ebx\n\t "movl $56, %esi\n\t "movl %ecx, $label(%edx,%ebx,$4)\n\t" "movb %ah, (%ebx)"); P-68/80

69 7.3 Efficiency Optimization of the Driver The Format of Extended Assembly : asm ( assembler template : output operands /* optional */ : input operands /* optional */ : list of clobbered registers /* optional */ ); Example : Using Assembly Instructions int a=10, b; b=a; P-69/80

70 7.3 Efficiency Optimization of the Driver Answer : int a=10, b; asm ("movl %1, %%eax; movl %%eax, %0;" :"=r"(b) /* output */ :"r"(a) /* input */ :"%eax" /* clobbered register */ ); P-70/80

71 7.3 Efficiency Optimization of the Driver Description "b" is the output operand, referred to by %0 and "a" is the input operand, referred to by %1. "r" says to GCC to use any register for storing the operands. Output operand constraint should have a constraint modifier "=". There are two % prefixed to the register name. This helps GCC to distinguish between the operands and registers. Operands have a single % as prefix. The clobbered register %eax after the third colon tells GCC that the value of %eax is to be modified inside "asm", GCC won t use this register to store any other value. P-71/80

72 7.3 Efficiency Optimization of the Driver Differences between X86 Assembly and ARM Assembly X86 Assembly mov %1,%%eax\n\t Source Destination Register Name: eax,ebx.etc. ARM Assembly mov %%r1,%1\n\t Source Destination Register Name: r1,r2.etc. P-72/80

73 P-73/ Efficiency Optimization of the Driver Example C Code #include<stdio.h> int main(void) { int i,j=0; for(i=0;i<100;i++) j=j+i; printf("%d",j); } ARM Assembly #include<stdio.h> int main(void) { int i,j=0; for(i=0;i<100;i++) asm ( "mov %%r1,%1\n\t" "mov %%r2,%2\n\t" "add %%r2,%%r1,%%r2\n\t" "mov %0,%%r2" :"=r"(j) :"r"(i),"r"(j) :"0"); printf("%d",j); }

74 P-74/ Efficiency Optimization of the Driver Example(cont.) C Code #include<stdio.h> int main(void) { int i,j=0; for(i=0;i<100;i++) j=j+i; printf("%d",j); } X86 Assembly #include<stdio.h> int main(void) { int i,j=0; for(i=0;i<100;i++) asm ( "mov %1,%%eax\n\t" "mov %2,%%ebx\n\t" "add %%eax,%%ebx\n\t" "mov %%ebx,%0" :"=r"(j) :"r"(i),"r"(j) :"0"); printf("%d",j); }

75 7.3 Efficiency Optimization of the Driver Example : MPEG-4 IDCT Driver (DCT Write) C Code ARM Assembly Assembly Optimized (Using LDMIA/STMIA order once, read/write into eight matevials.) P-75/80

76 7.3 Efficiency Optimization of the Driver C Code static ssize_t do_short_write (struct inode *inode,struct file *filp, int *buf, int count, loff_t *f_pos) { for(j=0; j<count; j++) { for(i=0;i<32;i++) { FPGA_in1=buf[i + j*32]; } } return 0; } P-76/80

77 7.3 Efficiency Optimization of the Driver ARM Assembly static ssize_t do_short_write (struct inode *inode, struct file *filp, int *buf, int count, loff_t *f_pos) { asm ( "STMFD r13!,{r0-r12}"); asm ( "mov %%R1,%0\n\t" "mov %%R0,%1" : :"r"(buf),"r"(count) ); P-77/80

78 7.3 Efficiency Optimization of the Driver ARM Assembly (cont.1) asm ( "mov %R11,#0\n\t" "LOOPJJ:\n\t" "MOV %R12,#0\n\t" "LOOPII:\n\t "MOV %R2,#128\n\t "MUL %R2,%R2,%R11\n\t "ADD %R2,%R2,%R12\n\t "ADD %R2,%R2,%R1\n\t "LDMIA %R2,{%R3-%R10}\n\t "MOV %R2,#0xF \n\t P-78/80

79 7.3 Efficiency Optimization of the Driver ARM Assembly (cont.2) "ADD %R2,%R2,#0x100\n\t "STMIA %R2,{%R3-%R10}\n\t "ADD %R12,%R12,#32\n\t" "CMP %R12,#128\n\t" "BLT LOOPII\n\t" "add %R11,%R11,#1\n\t "CMP %R11,%R0\n\t" "BLT LOOPJJ\n\t" ); asm ("LDMFD r13!,{r0-r12}"); return 0; } P-79/80

80 Reference Linux Device Drivers, 3rd Edition by Jonathan Corbet, Alessandro Rubini, Greg Kroah-Hartman. Linux Kernel Development, 2nd edition, by Robert Love. P-80/80