Linux I/O structure

1. 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 5007 - Noack

2. 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 5007 - Noack

3. 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 5007 - Noack

4. 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 5007 - Noack

5. 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 5007 - Noack

6. 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 5007 - Noack

7. 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 ICOM 5007 - Noack