Understanding Modern Device Drivers

Editor's Notes

• #16: First, we find that only 23% of overall driver code is dedicated to perform core I/O and interrupt processing. This means bulk of code in a driver is not towards core I/O and hence driver improvement should also look at non I/O code for improving the quality of drivers.
• #17: Next, we find that majority of driver code – about 36% is dedicated towards driver initialization and cleanup. Efforts at reducing the complexity of drivers should also focus on better mechanisms for driver initialization and cleanup. For example, as devices are increasingly becoming virtualization aware, quick ways to initialize devices are critical for important I/O virtualization features such as re-assignment of devices.
• #18: We also find, that the device configuration is the third biggest contributor to driver code. Network and video drivers have upto 30% of their code as device configuration. OS research should also look at better mechanisms for managing shared configuration code. About 6% of driver code is also exposed as opaque iocts. There are oppurtunites to make better interfaces and present more informed view of this part of configuration code to the kernel
• #19: We next look at whether drivers can be described based on their class definitions. Most drivers register a class interface with kernel to utilize device library services of that class. For example, PCI network drivers register with the network device subsystem and PCI bus subsystem to use its services. It is often assumed that drivers will behave within the boundaries of the class definition and the complete semantics of drivers can be understood by its registered calls to and from the kernel. However, many vendors introduce non-class behavior in driver to introduce non-standard features for competetive advantage in their products.
• #20: Most research assumes that drivers observe class behavior. For example, shadow drivers which automatically recovers device state after failures, records driver state based on class definition. It then replays this state upon failure, to bring back the driver to its previous state. ENTER. Non class behavior can lead to incomplete restore after failure since the state via non-class behavior is not recorded
• #21: Another example is reverse engineering of drivers.For example, a recent system, RevNIC records driver behavior state for one operating system and synthesizes it for another operating system by observing the traces. The traces are generated by invoking driver operations based on class behavior.PRESS Hence, non class behavior can lead to synthesis of incomplete driver.----- Meeting Notes (3/1/12 16:20) -----Drop this revnic
• #22: In Linux drivers, non class behavior manifests as load time parameters to the driver, unique ioctols to the device and interactions with the sys and proc file system. For, example, the Qlogic network driver shown in the figure, was detected by our analysis as an example of non-class behavior. The driver configuration settings are read from the sysfs and appropriate driver functions are called to change the driver state. This behavior is not recorded or invoked if one is only tracking class behavior operations.
• #23: We used our analyses to identify such behavior across all drivers and find that code supporting /proc and /sys is present in 16% of drivers. 36% of drivers have atleast one parameter to control behavior and configuration options not available through the class interface. Additionally, 16% of driver code contains ioctl, which can cause non-class behavior.Overall, 44% of drivers use one of the first two non-class features and such code breaks systems that use class behavior to interpret the semantics of drivers
• #24: Another common assumption is that drivers perform little processing and just shuttle data between OS and device. For example, automatic synthesis of drivers only allows operations primarily based on communicating data. It does not support memory transformations or processing made by drivers. However, if drivers perform processing for example to compute checksums for RAID, or to calculate display data, then automatic synthesis is unable to generate code for these parts of the driver
• #25: In order to detect processing, we detect loops in driver code that do not perform I/O, do not interact with kernel and lie on the core I/O path. The goal here was to detect driver code that transforms incoming or outgoing driver data in a loop without invoking a kernel service or making device calls. ENTER For example, in this figure, in the processing instance detected by our driver, we can see that the network driver is computing checksum for the network packets.
• #26: We also find other classes of drivers that perform processing. Here in this figure, we can see video processing being done by media drivers on the incoming video data. Other forms of processing include, wireless drivers which use processing to calculate power levels at different frequencies. Even CDROM drivers, use computation to analyze table of content information for CD-ROMS
• #27: We also see that higher percentage of network and sound drivers perform processing. These results have implications in not just automatic generation of drivers but also in virtualized settings where heavy I/O from one guest VM can substantially reduce CPU for other guest VMs without proper accounting.
• #28: We next looks at couple of results from our driver interactions study.
• #29: In this section, we look at how drivers use the kernel and how drivers communicate with devices? We see three reasons to study these interactions. First, extra processing power on devices or extra cores on host CPU provide an oppurtunity to redesign the driver architecture for improved reliability and performanceSecond, much of the difficulty in moving drivers comes from the driver/kernel interface, so investigating what drivers request from kernel can aid in designing more portable drivers. Third the cost of isolation and reliability are proportional to the size of the interface and the frequency of interactions, so understanding the interface can lead to more efficient fault tolerance mechanisms
• #30: We use our analyses to detect driver interactions with the kernel. The yaxis.. We classify these invocations based on 5 categories using static analysis: First is :Memory management (e.g. allocation): Second is Synchronization (e.g. Locks), Third is Kernel Library (generic stateless support routines – like timers, checksums, reporting etc. Fourth is Kernel Services (access to other subsystems like vfs, cpu, etc)Finally,Device Library (device subsystem supporting a class such as the network drivers)
• #31: While we expect diversity in kernel interaction, we see that some of the drivers such as ATA, IDE, gpio, drivers make limited use of kernel services.We look closely and find that in these drivers, rather than having a driver that invokes support routines, these drivers are a small set of device specific routines called from a much larger common driver. This design is similar to miniport drivers in Windows. ENTERConverting more drivers into this architecture can be benefical in reducing driver code as we see in the last part of the talk----- Meeting Notes (3/1/12 16:20) -----remove uwbdouble check acpi and gpio (and thats why they have simple)
• #32: We next look at portability of drivers? We look at what does the driver need the kernel for? If we want to run driver code elsewhere, such as user-mode, what does it need?Device library and kernel services require core kernel features which can be difficult to provide outside the kernel.Drivers with rich device library support are fairly limited (like network and sound) while other drivers such as video drivers have limited device library support and are more commonFrom our results, we see that most invocations are for kernel library routines, memory management and synchronization which are primary local to the driver and a driver executing in a separate execution context will not need to call into the kernel for these services. ENTER. Hence many driver classes such as crypto, firewire, media, mtd are portable to other environments.
• #33: We now study structural properties of drivers to identify differences between buses. We look for lessons on driver simplicity and performance. And review which buses support newer architectures that move drivers out of the kernel. We do so by looking at interface standardization and granularity of accesses across drivers from different buses. Both features are good indicators of portability of driver code
• #34: We first look to quantify efficiency of PCI devices. We intentionally pick a single class and compare how devices belong to a single class differ according to the bus. The table shows kernal and device interactions across all entrypoints for network drivers. The data about all classes is in the paper. PCI devices have fine grained and heavy access to kernel and driver. They support only 10 devices per driver which are usually from the same vendor. In order to support a new device, in most cases, one needs to write a new driver.Hence, we see that high performance of PCI drivers comes at a cost: increased driver complexity, and less interface standardization, and supporting a new device usually means writing a new driver
• #35: USB drivers are slightly more efficient and support almost 60% as many devices per driver often from many vendors. While the USB standardization efforts have been instrumental in increasing the bus efficiency The coarse grained interface to kernel and device offered by the bus also helps reducing driver code and produces better drivers. Here, a vendor can add non-standard code just for the features without creating new drivers in order to support a new device.
• #36: Xen pushes standardization further by supporting all drivers of a class using a single driver in the guest domain. Additional non-standard features can only be accessed from the domain executing the driver and are not available to guest OS. Hence, XEN can be more efficient than USB but one loses the ability to support non-standard driver code. Addition of non-standard behavior requires separate messaging protocol from outside the driver such as RPC. These results imply that Xen and USB provide interface standardization that could help move driver code away from the kernel and also provide a coarse grained accesses, reducing the cost of isolation.
• #37: I will now talk about redundancy in driver code
• #38: Given that all the drivers for a class perform essentially the same task, one may ask why so much code is needed. The problem of writing similar/repeated code is well documented. It causes bugs, prevents standardization and causes maintainability issues. Our goal in this section is to quantify the repeated code in drivers and what are the missing abstractions in that are creating repeated code.
• #39: We are not just looking for cloned code but similar code in drivers. To do so, we use an existing clustering technique from machine learning, called shape analysis, often used to cluster related documents. We generate a set of multi dimensonal coordinates representing the statement type and edit distance to represent the shape of every driver function. We then use a euclidean function to reduce these coordinates to a single signature value. This methodology helps us scale better to whole set of drivers since we are only comparing signature values. It also gives us a knob to control the amount of similarity that we wish to see by clustering signature values appropriately in the results obtained
• #40: We now look at two of the most commonsimilarity types identified by our analyses. Here is an example of similar code where we see drivers invoking device by using different register values!
• #41: This is an example of similar code found in drivers. We find here drivers are in many cases repeating wrappers around kernel functions in same sequence.
• #42: Overall we find 8% of driver code is very similar (which is approximately 400, 000 lines!)we find three cateogaries of similar code. First is calls to device/bus with different register values. Many drivers have a similar pattern of communicating with device, except using a different register values. This can be abstracted out by using a table driven programming, where common code executes and looks up tables to invoke appropriate device. Next is wrappers around kernel libraries, where kernel libraries are either missing interfaces or provide incomplete interfaces for accomplishing a task. For example, suspending a device requires holding appropriate locks, saving state, disabling device. Such wrappers are common across large number of drivers. Providing a common procedural abstraction for these kernel functions can help reduce driver code.Finally, we also see lots of repeated code amongst family of devices within a class. Provding object oriented design features or sub class librarries can further reduce this driver code.By removing these sources, one can reduce driver code, reduce incidence of bugs and improve software composability to support newer features such as power management.
• #43: To summarize, we review the large body of driver code and revisited generalizations about them and find that many assumptions about driver code do not hold. We also study interactions and reviewed how drive code can be moved away from kernel. We also, find missing interfaces in driver code, and providing them can reduce the driver code significantly.
• #46: This is an example of similar code in family of drivers. We see that much of the code is same, except for difference for driver data structures for different devices.----- Meeting Notes (2/28/12 16:28) -----example is badnot initialziing is not goodlook for wrappers (before and afer calls)? Look in paper----- Meeting Notes (3/1/12 16:20) -----add ide (in delkin_cb.c)FIX swap titlesCODE CAN BE ABSTRACTED (NOT CLEAR - REPEAT WRAPPERS AROUND KENRLE FNCITONS)
• #47: The Windows Driver Model, while a significant improvement over the VxD and Windows NT driver model used before it, has been criticised by driver software developers [1], most significantly for the following:WDM has a very steep learning curve.Interactions with power management events and plug and play are difficult. This leads to a variety of situations where Windows machines cannot go to sleep or wake up correctly due to bugs in driver code.I/O cancellation is almost impossible to get right.Thousands of lines of support code are required for every driver.No support for writing pure user-mode drivers.
• #49: This is an example of similar code in family of drivers. We see that much of the code is same, except for difference for driver data structures for different devices.----- Meeting Notes (2/28/12 16:28) -----example is badnot initialziing is not goodlook for wrappers (before and afer calls)? Look in paper
• #51: Cut out devices/driver
• #54: Gpu drivers do many register reads/wrtites before performing a DMA
• #55: Most research assumes that drivers observe class behavior. For example, shadow drivers which automatically recovers device state after failures, records driver state based on class definition. It then replays this state upon failure, to bring back the driver to its previous state. ENTER. Non class behavior…since the state via non-class behavior is not recorded