notes for linux device driver book, chap 1. Note: 3rd edition assumes linux kernel 2.6.10. see: preface sources of further info: e.g., 1. www.kernel.org - the kernel 2. http://www.linuxdoc.org - linux doc. project and HOWTOs 1. introduction to device drivers ... need device drivers ... there is always new hw. most active part of kernel development. unix is often behind for display controllers, network hw, etc ... but there is a lot going on. 2. role of the device driver very high level arch. principle: mechanism ... not policy: mechanism: what capabilities are provided. policy: how capabilities are used. graphic design: X server - reads/writes bits on a screen. understands hw but provides interface for other programs to draw on that hw. lib levelP: library level: athena widgets. fltk library apps: xterm, or xclock ... or xv ... or xearth OR KDE/GNOME - entirely different window mgmt systems. tcp/ip tcp provides file byte stream paradigm slogin/telnet/http/email/ftp/tftp/scp use it in different ways so consider: xearth/xclock/date should have what interface to the kernel's time? what should kernel time driver do? in general we want mechanism in the kernel ... for sharing. we want policy at a higher level. million-dollar-design-question: just what should API be between mechanism part and policy part. driver writing: kernel accesses hw ... should minimize policy in driver, maximize mechanism. policy-free-driver characteristics: 1. support for both async and sync access. block drivers ... 2. multiple opens when that makes sense so multiple programs can run concurrently. Does this make sense with a: 1. tape drive 2. floppy disk 3. network card 4. ram disk 3. policy-free code. you want low-level operations that mult. apps (or "clients") might use. kernel splitting process mgmt. memory mgmt. file systems block-device drivers used at lowest level here. although network access is another possibility for N.F.S. disks/tapes/cds/floppies device control character devices in particular UNIX makes them look SOMEWHAT like files, cat file > /dev/tty serial ports, serial multiplexors (N serial ports, say 16). note serial ports have many bizarre special needs, for example,, due to traditional RS-232 control lines for modems. "loss of carrier" (modem connection lost). virtual console device/s. keyboard input device mouse (generates X, Y coordinates as a few bytes) networking ethernet/wireless, etc. device drivers loadable modules we can dynamically load drivers and possibly even stranger things (web servers?) become part of kernel's address space. dynamically linked # insmod foo.ko # lsmod # rmmod See Figure 1-1. Classes of Devices/Modules character devices: driver implements open/close/read/write, file stream as a virtual concept. /dev/console - text console serial ports /dev/ttyS0 etc. stty control functions may also have mapped character devices (read/write bytes) that can appear directly in memory. This is how the X server accesses screen memory. good question: does mmap work? does lseek work? do they work on serial ports? does open/close/read/write work on a display controller? block devices: block i/o oriented, although some false character device access exists. /dev/hdaX - block at bottom of mounted file system. hd device driver, floppy device driver, etc. open/close/read/write work on high-level FS, which issues block read/write requests to device. [root@zymurgy root]# df Filesystem 1k-blocks Used Available Use% Mounted on /dev/hda3 27585276 3737124 22446884 15% / /dev/hda2 46668 9053 35206 21% /boot none 127672 0 127672 0% /dev/shm Due to # mount /dev/hda3 / ... may have character devices that allow applications to directly access file system blocks. used by fsck/dd or forensics/crackers ... or whatever network devices at bottom of network stack. manipulated by ifconfig. #ifconfig eth0 not mapped into /dev as hd is. bus mappings device driver has to deal with SCSI, which you can view as a device language of its own. Or gpib ... which is a serial-bus language. we can view a bus as a possible class mechanism. E.g., add pccard support ... there will be general operations and individual hw functions too for a wide-range of card types. Plus general control functionality as well. E.g., cardctl(8). security issues: remember this security principle: weakest link ... security bugs may cause the loss of your system and can be considered more lethal that your average bug users can cause damage by deliberate exploitation of bugs users can cause damage by accidental exploitation of bugs idea: avoid security policy implementation where possible. Not always possible. Consider 2 kinds of device access: 1. mediated by kernel; e.g., file-system access. Therefore device driver does not check for file permissions because it only knows blocks. 2. not mediated by kernel; e.g., wireless packet driver allows change of channel. Might want to make this root only. avoid buffer-overflow bugs. user inputs should be checked and double checked. This is good kernel practice anyway ... no fun to have to reboot. kernel coding philosophy goes like this anyway: 1. check the inputs and make sure they are ok, else return ERROR now 2. do what was asked be careful about 3rd party software. You may be about to load krnsniff.ko a loadable module could be an explicit exploit or an implicit buggy thing You may compile to have no loadable modules. version numbering: stable kernel: even-numbered; e.g., 2.2, 2.4, 2.6 experimental kernel: odd-numberd; e.g., 2.3, 2.5 changes with 2.6 bigger kernel api changes have started to be accepted. this means the moving target (where this book is concerned too) is moving faster.