ICOM Noack Linux I/O structure Device special files Device switch tables and fops How the kernel finds a device Parts of a device driver or module Device driver actions

ICOM Noack Level of kernel support No support Application program interacts with I/O ports directly – driver is just a stub Example – graphics drivers – X-server (an application program) deals with graphics card directly Minimal support Kernel doesn’t understand device, just interface registers and functioning Example – serial port – application program understands modem or other associated device Extended support Kernel (device driver) understands device as well as interface Example – most drivers except graphics and serial

ICOM Noack Device special files File actions (read, write, etc.) on a device special file cause interaction with the device The inode for a device special file contains Type – block or character Major number – which device driver to use Minor number – which instance of this kind of device No data or data block pointers at all The name of a device file usually means nothing Commonly these files go in /dev Examples - /dev/hdxx – hard disks, /dev/console – system console Newer scheme is used in linux-2.4 – /devfs – device files are automatically created when a device is found

ICOM Noack Device switch tables and fops Each table (block or character) contains Prefix – a short device type mnemonic – prefixes each entry name Pointer to a fops data structure – members are named open, read, write, etc. Values are function pointers to entry points in the device driver or module The fops structure is an additional level of indirection and flexibility Using a pointer to a derived structure allows additional capabilities for specific devices This general idea is an example of an implementation detail A given function can be done in any of many ways without changing the external behavior of the system Often such details are chosen for better compartmentalization or flexibility

ICOM Noack How the kernel finds a device PCI devices Pci interfaces can be initialized to set up port, interrupt line, and on-interface memory Devices can identify their type OS then sets up interrupt vectors and links them to the appropriate handler OS registers these devices Hot pluggables Identified when they appear on USB or other bus during run time – drivers or modules are registered then Legacy devices CPU probes for these at boot time – it can hang system or confuse device Probing is designed to cause device to interrupt so OS can find out which line is connected

ICOM Noack Parts of a device driver or module Upper half Contains all the fops-based entry points – kernel and user space – kernel mode Lower half Operations that can be called by some kind of scheduling queue – also kernel and user space Bottom half The interrupt service routines – kernel memory only

ICOM Noack Device driver actions Fops structure Default members connect to nothing (except for open) Usual members connect to the standard methods – read, write, etc. Member assignments can be changed – introducing new or different methods Interrupt usage Driver can request_irq() or freee_irq() Request_irq() is called in the open() method free_irq() is called in the release() method if the usage count has dropped to zero Synchronization Driver that has interrupt handler starts I/O and then does interruptible_sleep_on() – passing a pointer via the interrupt queue Polling drivers can do spinlocks (for short displays) or put themselves on a scheduling queue if the operation is long