slide1
Download
Skip this Video
Download Presentation
Melekam Tsegaye [email protected]

Loading in 2 Seconds...

play fullscreen
1 / 32

Melekam Tsegaye [email protected] - PowerPoint PPT Presentation


  • 148 Views
  • Uploaded on

A Comparative Study of the Linux and Windows Device Driver Architectures with a focus on IEEE1394 (high speed serial bus) drivers. Melekam Tsegaye [email protected] Supervisors Prof. Richard Foss, Bradley Klinkradt. Overview. The Linux and Windows driver architectures

loader
I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
capcha
Download Presentation

PowerPoint Slideshow about 'Melekam Tsegaye [email protected]' - thane-robbins


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.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.


- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
slide1

A Comparative Study of the Linux and Windows Device Driver Architectures with a focus on IEEE1394 (high speed serial bus) drivers

Melekam Tsegaye

[email protected]

Supervisors Prof. Richard Foss, Bradley Klinkradt

overview
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
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
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
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
Typical driver routines
  • A driver would implement
    • Initialisation
    • Cleanup
    • Open
    • Read
    • Write
    • I/O Control (ioctl)
    • Close
the windows driver architecture
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
The Linux driver architecture
  • No standard driver model
    • Drivers are modules
    • No PnP & Power management message dispatching
    • Communication through direct function calls
ieee 1394 driver stacks
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
The Windows IEEE 1394 stack
  • Host controller
  • Bus driver
  • Client drivers
  • Communication
    • I/O request block (IRB)
the linux ieee 1394 stack
The Linux IEEE 1394 stack
  • Host controller
  • Bus drivers
  • Client drivers
  • Communication
    • direct function calls
  • Direct driver possible
what operations should ieee 1394 client drivers provide
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
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
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
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
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
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
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
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
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
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
ad