understanding modern device drivers why study device
play

Understanding Modern Device Drivers Why study device drivers? Linux - PDF document

3/6/12 Understanding Modern Device Drivers Why study device drivers? Linux drivers constitute ~5 million LOC and 70% of kernel Little exposure to this breadth of driver code from research Better understanding of drivers can lead to


  1. 3/6/12
 Understanding Modern Device Drivers Why study device drivers? » Linux drivers constitute ~5 million LOC and 70% of kernel » Little exposure to this breadth of driver code from research » Better understanding of drivers can lead to better driver model » Large code base discourages major changes » Hard to generalize about driver properties » Slow architectural innovation in driver subsystems » Existing architecture: Error prone drivers » Many developers, privileged execution, C language » Recipe for complex system with reliability problems Asim Kadav and Michael M. Swift University of Wisconsin‐Madison 2 Difficult to validate research on all drivers Our view of drivers is narrow » Driver research is focused on reliability Improvement System Validation » Focus limited to fault/bug detection and tolerance Drivers Bus Classes New functionality Shadow driver migration [OSR09] 1 1 1 » Little attention to architecture/structure RevNIC [Eurosys 10] 1 1 1 Reliability Nooks [SOSP 03] 6 1 2 » Driver research only explores a small set of drivers XFI [ OSDI 06] 2 1 1 » Systems evaluate with mature drivers CuriOS [OSDI 08] 2 1 2 » Volume of driver code limits breadth Type Safety SafeDrive [OSDI 06] 6 2 3 Singularity [Eurosys 06] 1 1 1 » Necessary to review current drivers in modern settings Specification Nexus [OSDI 08] 2 1 2 Termite [SOSP 09] 2 1 2 Static analysis tools SDV [Eurosys 06] All All All Device availability/slow driver development restrict our Carburizer [SOSP 09] All/1 All All research runtime solutions to a small set of drivers Cocinelle [Eurosys 08] All All All 3 4 1


  2. 3/6/12
 Difficult to validate research on all drivers Understanding Modern Device Drivers Improvement System Validation » Study source of all Linux drivers for x86 (~3200 drivers) Drivers Bus Classes “...Please do not misuse these tools! New functionality Shadow driver migration [OSR09] 1 1 1 » Understand properties of driver code (Coverity).... If you focus too much on » What are common code characteristics? RevNIC [Eurosys 10] 1 1 1 fixing the problems quickly rather than » Do driver research assumptions generalize? Reliability Nooks [SOSP 03] 6 1 2 fixing them cleanly, then we forever XFI [ OSDI 06] 2 1 1 lose the opportunity to clean our code, » Understand driver interactions with outside world CuriOS [OSDI 08] 2 1 2 » Can drivers be easily re‐architected or migrated ? because the problems will then be Type Safety SafeDrive [OSDI 06] 6 2 3 » Can we develop more efficient fault‐isolation mechanisms? hidden.” Singularity [Eurosys 06] 1 1 1 Specification Nexus [OSDI 08] 2 1 2 » Understand driver code similarity LKML mailing list http://lkml.org/lkml/2005/3/27/131 Termite [SOSP 09] 2 1 2 » Do we really need all 5 million lines of code? Static analysis tools SDV [Eurosys 06] All All All » Can we build better abstractions? Carburizer [SOSP 09] All/1 All All Cocinelle [Eurosys 08] All All All 5 6 Outline Methodology of our study » Target Linux 2.6.37.6 (May 2011) kernel Methodology » Use static source analyses to gather information hwmon char drivers input isdn Driver code characteristics leds Percent- media age of LOC message misc parport 0 10 platform 20 pnp serial 30 40 sound 50 tty video » Perform multiple dataflow/control‐flow analyses watchdog ata Percentage of threaded vs event friendly fu » Detect driver properties of the drive code 80 70 Driver interactions 60 50 40 » Detect driver code interactions with environment 30 20 10 0 acpi etooth crypto ewire gpio gpu wmon input isdn leds edia misc rport pnp serial sound video hdog ata ide md mtd scsi atm infiniband net uwb » Detect driver code similarities within classes If If Goto Goto Code Type Loop/Brk/Cont Loop/Brk/Cont Driver redundancy Return Return Call Call Set Set 1 , 300 1 , 310 1 , 320 1 , 330 1 , 340 1 , 350 1 , 690 1 , 700 1 , 710 1 , 720 1 , 730 net/dl 2 k.c net/ 82596 .c If If Goto Goto Code Type Loop/Brk/Cont Loop/Brk/Cont Return Return Call Call Set Set 7 8 2


  3. 3/6/12
 Extract driver wide properties for individual drivers Determine code characteristics of each driver function Kernel registration Bus type registered with the kernel Identify driver Bus type registered with the kernel entry points, Device class registered with the kernel Record driver init driver data Device class registered with the kernel config properties using structures, kernel Device sub class registered with the kernel cleanup multiple control/data allocate registration Device sub class registered with the kernel flow analysis MTU Driver functions mapped to entry points power destroy Driver functions mapped to entry points speed Tag each reachable up intr driver function pci unregister Number of devices registered with the bus Number of devices registered with the bus resume with entry point I/O information suspend Other properties (module parameters etc) calculate Other properties (module parameters etc) signal Length of the driver functions Length of the driver functions Device invocations Step 1: Determine driver code characteristics for each driver Step 2: Propagate the required information to driver from driver data structures registered with the kernel functions and collect information about each function 9 10 Determining interactions of each driver function Outline Methodology Kernel registration Undefined kernel functions Kernel interaction across entry points init classified by type (device/kernel config libraries, memory management, synchronization, services cleanup hwmon Device interaction across entry points char drivers allocate input isdn Driver code characteristics leds Percent- MTU media age of LOC message misc parport 0 power + 10 Di fg erence in driver structures across platform 20 destroy pnp speed serial 30 buses 40 up sound 50 tty video intr watchdog pci unregister ata resume Device calls - port/mmio, DMA, I2C Bus type registered with the kernel operations, bus library invocations I/O Percentage of threaded vs event friendly fu 80 suspend 70 Driver interactions calculate 60 Threading/Synchronization models used 50 signal 40 30 20 10 0 acpi etooth crypto ewire gpio gpu wmon input isdn leds edia misc rport pnp serial sound video hdog ata ide md mtd scsi atm infiniband net uwb Device invocations If If Goto Goto Code Type Loop/Brk/Cont Loop/Brk/Cont Driver redundancy Return Return Call Call Set Set 1 , 300 1 , 310 1 , 320 1 , 330 1 , 340 1 , 350 1 , 690 1 , 700 1 , 710 1 , 720 1 , 730 Step 3: Determine driver interactions from I/O operations and calls net/dl 2 k.c net/ 82596 .c If If Goto Goto Code Type Loop/Brk/Cont Loop/Brk/Cont Return Return to kernel and bus for each function and propagate to entry points Call Call Set Set 11 12 3


  4. 3/6/12
 1‐a) Driver Code acpi Part 1: Driver Code Behavior bluetooth Characteristics cdrom char crypto edac fi rewire » Core I/O & interrupts – 23% gpio A device driver can be thought of as a translator. Its input gpu » Initialization/cleanup – 36 % hid consists of high level commands such as “retrieve block 123”. hwmon char drivers input » Device configuration – 15% Its output consists of low level, hardware specific instructions isdn leds » Power management – 7.4% media that are used by the hardware controller, which interfaces message » Device ioctl – 6.2% misc the I/O device to the rest of the system. parport platform pnp ‐‐ Operating System Concepts VIII edition serial sound Percent- tty age of LOC video watchdog ata Driver code complexity and size is assumed to be a result 0 block drivers block ide 10 of its I/O function. md mtd 20 scsi 30 atm net drivers in fi niband 40 net uwb 50 13 14 init cleanup ioctl con fi g power error proc core intr Driver Code Driver Code acpi acpi bluetooth Characteristics bluetooth Characteristics cdrom cdrom char char crypto crypto edac edac fi rewire fi rewire » Core I/O & interrupts – 23% » Core I/O & interrupts – 23% gpio gpio gpu gpu » Initialization/cleanup – 36 % » Initialization/cleanup – 36 % hid hid hwmon hwmon char drivers char drivers input input » Device configuration – 15% » Device configuration – 15% isdn isdn leds leds » Power management – 7.4% » Power management – 7.4% media media message message » Device ioctl – 6.2% » Device ioctl – 6.2% misc misc parport parport platform platform pnp pnp serial serial sound Percent- sound Percent- tty tty age of LOC age of LOC video video watchdog watchdog ata ata 0 0 Driver code complexity Only 23% of driver block block block drivers block drivers ide ide 10 10 stems mostly from md code is dedicated to I/O md mtd 20 mtd 20 scsi scsi initialization/cleanup and interrupts 30 30 atm atm net drivers net drivers in fi niband in fi niband code. 40 40 net net uwb 50 uwb 50 15 16 init cleanup ioctl con fi g power error proc core intr init cleanup ioctl con fi g power error proc core intr 4


Recommend


More recommend