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

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

3. Why the study was conducted ? Microsoft Windows and Linux Two of the most popular operating systems Two of the most popular operating systems No previous comparisons of their driver architectures done by other researchers No previous comparisons of their driver architectures done by other researchers IEEE 1394 (firewire) Popular bus offering high data transfer rates Popular bus offering high data transfer rates Active research area for the CS department’s Audio Engineering Group Active research area for the CS department’s Audio Engineering Group

4. IEEE 1394 Data Transfer rates of 100, 200 and 400 Mbps Isochronous mode of transfer Guaranteed bandwidth (80%) Guaranteed bandwidth (80%) Asynchronous mode of transfer Guaranteed packet delivery (20% or more) Guaranteed packet delivery (20% or more) Fully plug ‘n play

5. IEEE 1394 Consumer Products

6. 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 transfer data to and from a device to control the a device to allow modification of its attributes 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

7. Typical driver routines A driver would implement Initialisation Initialisation Cleanup Cleanup Open Open Read Read Write Write I/O Control (ioctl) I/O Control (ioctl) Close Close

8. The Windows driver architecture Standard model The Windows Driver Model (WDM) The Windows Driver Model (WDM) bus, functional & filter drivers PnP & Power management PnP & Power management Communication Communication I/O request packets (IRPs) I/O request packets (IRPs)

9. The Linux driver architecture No standard driver model Drivers are modules Drivers are modules No PnP & Power management message dispatching No PnP & Power management message dispatching Communication through direct function calls Communication through direct function calls

10. Side by side comparison of the two driver architectures Linux Windows

11. IEEE 1394 driver stacks The Windows IEEE 1394 stack closed source closed source maintained by Microsoft maintained by Microsoft stable stable The Linux IEEE 1394 stack open source open source maintained by the Linux 1394 community (private individuals) maintained by the Linux 1394 community (private individuals) tagged experimental tagged experimental

12. The Windows IEEE 1394 stack Host controller Bus driver Client drivers Communication I/O request block (IRB) I/O request block (IRB)

13. The Linux IEEE 1394 stack Host controller Bus drivers Client drivers Communication direct function calls direct function calls Direct driver possible

14. Side by side comparison of the two IEEE 1394 stacks Linux Windows

15. The Windows IEEE 1394 implementation

16. The Linux IEEE 1394 implementation

17. What operations should IEEE 1394 client drivers provide ? Asynchronous Operations Read Read Write Write Lock Lock Listen Listen Register Asynchronous Listening Register Asynchronous Listening Deregister Asynchronous Listening Deregister Asynchronous Listening Isochronous operations Listen Listen Talk Talk Asynchronous streaming Asynchronous streaming

18. What operations should IEEE 1394 client drivers provide ? (Continued) Bus reset handling Register Bus Reset Handler Register Bus Reset Handler Generate Soft Bus Reset Generate Soft Bus Reset Obtain Bus Information (e.g. node count) Local configuration ROM manipulation Network troubleshooting Pinging of nodes Pinging of nodes

19. Device Driver Development Environments

20. Issues to be considered when creating drivers Memory management The kernel provides memory allocation/de- allocation routines The kernel provides memory allocation/de- allocation routines Has two pools of memory (swappable, non- swappable) Has two pools of memory (swappable, non- swappable) Data structures The kernel provides implementations for queues, lists, stacks The kernel provides implementations for queues, lists, stacks Synchronisation with spin locks, mutexes, semaphores, signal objects Synchronisation with spin locks, mutexes, semaphores, signal objects

21. 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 must be re-entrant i.e. should be executable by multiple threads with no problems avoid recursion avoid recursion Hardware Abstraction Layer use HAL routines provided by the kernel to access hardware use HAL routines provided by the kernel to access hardware

22. Map of software produced during this study

23. Windows raw1394 driver

24. Linux raw1394-2 driver

25. Linux Ieee1394diag

26. Driver Tests Tests were run to determine highest data transfer rates that can be achieved by each of the IEEE 1394 drivers 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 how close these came to the theoretical maximum of 50MB/s Bus analyser used to measure the duration of data transfers the duration of data transfers the amount of data transferred the amount of data transferredCalculated the data transfer rate in MB/s the data transfer rate in MB/s

27. Test results Isochronous mode Windows raw1394 Windows raw1394 8.9 MB/s packet size 1024 bytes Linux raw1394 Linux raw1394 4.5 MB/s packet size 512 bytes Isochronous mode (buffered) Linux raw1394-2 Linux raw1394-2 8.9 MB/s packet size 1024 bytes Windows raw1394 Windows raw1394 17.7 MB/s packet size 2048 bytes

28. Test results (continued) Drivers from both Linux and Windows do not transfer data at a rate close to the theoretical 50MB/s 50MB/s They achieve almost half that They achieve almost half that due to the PCI bus bottleneck (theoretical 132MB/s) In practice have that available In practice have that available shared by all I/O devices attached to the PCI bus shared by all I/O devices attached to the PCI bus The PCI bus has latency problems The PCI bus has latency problems driver implementation may not be efficient

29. Conclusion A comparison of the Windows and Linux driver architectures has shown that Drivers for the two platform have similar components Drivers for the two platform have similar components composed of routines for performing composed of routines for performing I/O and device control I/O and device control drivers are modules which are loadable at runtime drivers are modules which are loadable at runtime Windows has a formally defined driver model, Linux does not. Windows has a formally defined driver model, Linux does not. PnP and power management support integrated in the Windows architecture, not so in Linux PnP and power management support integrated in the Windows architecture, not so in Linux

30. 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 Their IEEE 1394 driver stacks are broken up into similar layers host controller, bus and client driver layers host controller, bus and client driver layers Each stack provides the standard IEEE 1394 operations (both asynchronous and isochronous) 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 Easier to create IEEE 1394 drivers for Linux than Windows since all source code is available

31. Future work IEEE 1394.1 bridge awareness IEEE 1394.1 allows extending the no. of nodes to 64K instead of the current 63 allows extending the no. of nodes to 64K instead of the current 63 still in draft phase 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 implementation possible for the Linux 1394 stack not for the Windows 1394 stack (closed source) 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 no IEEE 1394.1 bridging hardware available the standard may change the standard may change

32. Questions ?