1 / 7

Linux I/O structure

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. Level of kernel support. No support Application program interacts with I/O ports directly – driver is just a stub

hateya
Download Presentation

Linux I/O structure

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  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

More Related