1 / 19

I/O Device Connection in Linux

I/O Device Connection in Linux. Michael J. Feinberg Michael.Feinberg@UConn.Edu Ken Cook K.Cook@UConn.Edu CSE258 Linux Project November 30, 1999. Introduction: What are we talking about??. How I/O devices can interact and are connected to the Linux operating system.

adonis
Download Presentation

I/O Device Connection in Linux

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. I/O Device Connection in Linux Michael J. Feinberg Michael.Feinberg@UConn.Edu Ken Cook K.Cook@UConn.Edu CSE258 Linux Project November 30, 1999

  2. Introduction: What are we talking about?? • How I/O devices can interact and are connected to the Linux operating system. • How architecture is used by Linux (i.e. Interrupts, DMA, etc.) • The device drivers that kernel depends upon to communicate to the device • How the device is represented within Linux • Attempt to note things were taken into account due to Linux’s ability to run a variety of architectures.

  3. Sorry to Interrupt... • Linux takes advantage of an interrupt architecture • Interrupt assignment varies depending on the device. • Some devices are assigned interrupts due to legacy architecture EXAMPLE:FLOPPY DRIVES ARE ASSIGNED IRQ 6 • PCI devices are assigned IRQ’s dynamically on boot-up • Intel x86 Architecture relies on PC BIOS • ALPHA XPD architecture has no BIOS, so assignment is handled by Linux.

  4. ISA, old chum... • In the case of ISA, the device is not aware inherently of its IRQ Linux Deals • Once an action causes an ISA device to be intterrupted, Linux activates all it’s unassigned IRQ’s • If the ISA is fortunate enough to find an unused IRQ, it shall use it as if it were directly assigned.

  5. Handling Interrupts • Uses a set of pointers to data structures containing the addresses of the routines within the device driver that handle the system's interrupts • It is the responsibility of each device driver to request the interrupt that it wants when the driver is initialized. • Kernel determines what device called the interrupt by checking the status registers of the programmable interrupt controllers. • Kernel generates an offset into the irq_action vector. • irq_action vector contains pointers to subroutines for each device • Subroutines are contained in the Device Driver.

  6. Little DMA... • Linux uses and suffers through the limitations of DMA • Limited to 7 DMA channels • These channels can’t be shared • DMA needs a contiguous block of memory • Circumvents virtual memory due to it’s direct nature. • Needs to take percautions so the “Direct” pages aren’t swapped out. (i.e. locking the pages) • DMA only has 24-bits for addressing • DMA can only access the lower 16MB of primary memory

  7. The Structure of DMA • Tracks the usage of the DMA channels using a vector of dma_chan data structures. • one per DMA channel • The dma_chan data structure contains just two fields • a pointer to a string describing the owner of the DMA channel • flag indicating if the DMA channel is allocated or not. • vector of dma_chan data structures that is printed when you cat/proc/dma.

  8. Driver Chooses DMA • The device driver to determine which DMA channel it should use. • some devices have a fixed DMA channel • Sometimes the DMA channel by jumpers • others the device driver can simply pick a free DMA channel • Adds more complication to the driver creation process

  9. Device Driver • The Kernel code that communicates with the device • Ideally the code should be relatively generic for the kernel to know how to handle each device. • Linux handles this by breaking all device drivers into three categories

  10. Terrific Trio Definitions • Character Devices • Read/Write a single byte at a time • Keyboards • Serial Devices • Handle their own buffering • Block Devices • Transfer data blocks @ a time • Data Storage Devices (Hard Drives) • Block sizes usually range 512 to 1024 bytes • Rely on the Kernel to their buffering • Network Devices • Transfers data @ a packet level

  11. THE BENEFIT OF ABSTRACTION • By creating this separation…. • The kernel can ignore the details of a specific device. • Allows the kernel to create generic functions for interaction.

  12. Where to park the drivers... • Compiled into the kernel • Added in as a module….. • So Dynamic…How will Linux handle a varying system???

  13. Desperately Seeking Devices • Hardware is searched for and Registered at boot-up • Devices are “found” by their descriptions are added to a number of System Tables. • character devices are added to the chrdevs vector • block devices are added to blkdevs vector • Network devices are handled through the network systems

  14. Re-cap • It has been established the main controls and interface with the CPU is interrupt and DMA driven • Device driver contains the routines that interrupts use to work with the device. • How are the devices represented, so that the drivers can communicate with them???

  15. It’s all about the files, baby. • All devices with in the system are represented by a Device Special File • Character and Block device “Device Special Files” are generated using the mknod (make node) command. • Network device “Device Special Files” are created during the intialization of the network subsystem. • Technically these files can be found anywhere in the system. • By convention they are found in the /dev directory of the system.

  16. File Description • Linux’s “Device Special File” convention allows devices to be described as any other file on Linux: • DEVICE CLASSIFICATION: • “C” for Character device, “B” for block device. • DEVICE TYPE: • TTY describes is a Teletype type. • MAJOR NUMBER: • Uniquely assigned per device driver in the system • MINOR NUMBER: • Uniquely assigned per partition • DEVICE ID: • Unique name of the “Device Special File”

  17. Benefits of The File Convention • Can take advantage of Linux Permission structures • Can take advantage of Linux Permission structures • CD-ROM is treated as a read-only device • I/O devices can be treated as read/write devices

  18. Finally……. Conclusion • Presentation a very high level view how devices interact with Linux • Started with tools the kernel and architecture have to deal with devices. • Described the means of connecting to the device…The Device Driver. • Covered the how Device can be interfaced, (i.e. what conventions are used by the OS to connect to a device. • Represents the power of keeping things general • The kernel separation of the devices into the 3 categories, provided the flexibily of more devices • File convention allows for an “easier” for programs to deal with the devices. • The extensibility provided by these features is one of the main features to why Linux/Unix has lasted so long

  19. For more information... • Http://www.informit.com ((Free library on a variety of topics including Linux and other OS’s)) Linux SA Survival Guide and Red Hat Linux Unleashed. • http://sunsite.unc.edu/LDP/ldp.html ((The Linux Documentation Project)) David A Rusling’s The Linux Kernel Thank You

More Related