320 likes | 492 Views
A Comparative Study of the Linux and Windows Device Driver Architectures with a focus on IEEE1394 (high speed serial bus) drivers. Melekam Tsegaye g98t4414@campus.ru.ac.za. Supervisors Prof. Richard Foss, Bradley Klinkradt. Overview. The Linux and Windows driver architectures
E N D
A Comparative Study of the Linux and Windows Device Driver Architectures with a focus on IEEE1394 (high speed serial bus) drivers Melekam Tsegaye g98t4414@campus.ru.ac.za Supervisors Prof. Richard Foss, Bradley Klinkradt
Overview • The Linux and Windows driver architectures • The Linux and Windows IEEE 1394 driver stacks • Driver development on the two platforms • Results of the study
Why the study was conducted ? • Microsoft Windows and Linux • Two of the most popular operating systems • No previous comparisons of their driver architectures done by other researchers • IEEE 1394 (firewire) • Popular bus offering high data transfer rates • Active research area for the CS department’s Audio Engineering Group
IEEE 1394 • Data Transfer rates of 100, 200 and 400 Mbps • Isochronous mode of transfer • Guaranteed bandwidth (80%) • Asynchronous mode of transfer • Guaranteed packet delivery (20% or more) • Fully plug ‘n play
Device Drivers • A driver is a piece of software that extends a kernel’s functionality • Drivers enable applications (through the kernel) • to transfer data to and from a device • to control the a device to allow modification of its attributes • Composed of a set of routines that a kernel calls at appropriate times e.g. read/write
Typical driver routines • A driver would implement • Initialisation • Cleanup • Open • Read • Write • I/O Control (ioctl) • Close
The Windows driver architecture • Standard model • The Windows Driver Model (WDM) • bus, functional & filter drivers • PnP & Power management • Communication • I/O request packets (IRPs)
The Linux driver architecture • No standard driver model • Drivers are modules • No PnP & Power management message dispatching • Communication through direct function calls
Side by side comparison of the two driver architectures Linux Windows
IEEE 1394 driver stacks • The Windows IEEE 1394 stack • closed source • maintained by Microsoft • stable • The Linux IEEE 1394 stack • open source • maintained by the Linux 1394 community (private individuals) • tagged experimental
The Windows IEEE 1394 stack • Host controller • Bus driver • Client drivers • Communication • I/O request block (IRB)
The Linux IEEE 1394 stack • Host controller • Bus drivers • Client drivers • Communication • direct function calls • Direct driver possible
Side by side comparison of the two IEEE 1394 stacks Linux Windows
What operations should IEEE 1394 client drivers provide ? • Asynchronous Operations • Read • Write • Lock • Listen • Register Asynchronous Listening • Deregister Asynchronous Listening • Isochronous operations • Listen • Talk • Asynchronous streaming
What operations should IEEE 1394 client drivers provide ? (Continued) • Bus reset handling • Register Bus Reset Handler • Generate Soft Bus Reset • Obtain Bus Information (e.g. node count) • Local configuration ROM manipulation • Network troubleshooting • Pinging of nodes
Issues to be considered when creating drivers • Memory management • The kernel provides memory allocation/de-allocation routines • Has two pools of memory (swappable, non-swappable) • Data structures • The kernel provides implementations for queues, lists, stacks • Synchronisation with spin locks, mutexes, semaphores, signal objects
Issues to be considered when creating drivers (Continued) • Drivers routines • must be re-entrant i.e. should be executable by multiple threads with no problems • avoid recursion • Hardware Abstraction Layer • use HAL routines provided by the kernel to access hardware
Driver Tests • Tests were run to determine • highest data transfer rates that can be achieved by each of the IEEE 1394 drivers • how close these came to the theoretical maximum of 50MB/s • Bus analyser used to measure • the duration of data transfers • the amount of data transferred • Calculated • the data transfer rate in MB/s
Test results • Isochronous mode • Windows raw1394 • 8.9 MB/s • packet size 1024 bytes • Linux raw1394 • 4.5 MB/s • packet size 512 bytes • Isochronous mode (buffered) • Linux raw1394-2 • 8.9 MB/s • packet size 1024 bytes • Windows raw1394 • 17.7 MB/s • packet size 2048 bytes
Test results (continued) • Drivers from both Linux and Windows do not transfer data at a rate close to the theoretical • 50MB/s • They achieve almost half that • due to the PCI bus bottleneck (theoretical 132MB/s) • In practice have that available • shared by all I/O devices attached to the PCI bus • The PCI bus has latency problems • driver implementation may not be efficient
Conclusion • A comparison of the Windows and Linux driver architectures has shown that • Drivers for the two platform have similar components • composed of routines for performing • I/O and device control • drivers are modules which are loadable at runtime • Windows has a formally defined driver model, Linux does not. • PnP and power management support integrated in the Windows architecture, not so in Linux
Conclusion (continued) • A comparison of the Windows and Linux IEEE 1394 stacks has shown that • Their IEEE 1394 driver stacks are broken up into similar layers • host controller, bus and client driver layers • Each stack provides the standard IEEE 1394 operations (both asynchronous and isochronous) • The Linux IEEE 1394 stack is open source while the Windows stack is proprietary • Easier to create IEEE 1394 drivers for Linux than Windows since all source code is available
Future work • IEEE 1394.1 bridge awareness • IEEE 1394.1 • allows extending the no. of nodes to 64K instead of the current 63 • still in draft phase • The Windows and Linux IEEE 1394 driver developers did not take into account IEEE1394.1 bridging in their design • This study identified bridge awareness requirements • implementation possible for the Linux 1394 stack • not for the Windows 1394 stack (closed source) • Full IEEE 1394.1 implementation and testing not done during this study • no IEEE 1394.1 bridging hardware available • the standard may change