1. Understanding the Genetic Makeup of Linux Device Drivers
Peter Senna Tschudin, Laurent Réveillère,
Lingxiao Jiang, David Lo, Julia Lawall, Gilles Muller
LIP6 – Inria & UPMC, LaBRI, Singapore Management University

2. What is a device driver Data translator between OS and device
Also performs computations, such as checksums
2 /

3. Device Driver Development Issues
Port
Write
Maintain
Backport
Complex
Expensive
Slow
Error-prone
3 /

4. What has been proposed... Domain-specific languages: Devil [OSDI 2000]
Automatic synthesis of provably correct drivers from specification: Termite [SOSP 2009]
Templates: RevNIC [Eurosys 2010]
4 /

5. ... is not for all drivers Unsupported classes of devices
Unsupported complex and firmware dependent devices
Intellectual property can limit access to device specification
Code generated by tools should be accepted by OS development communities
5 /

6. Our vision
There are already good drivers
Billions of instances of device drivers running right now
Some have being developed for many years
Used in mission critical environments (we are all alive)
How to exploit the knowledge found in good drivers to help us make new ones?
6 /

7. Urban legend: Device drivers are implemented by copy-paste
Possible solution
Urban legend: Device drivers are implemented by copy-paste
CP-Miner [OSDI 2004]:
Up to 22.3% of Linux code is involved in clones
Most common copy-paste groups contain only 2 copies
Most common copy-paste segment size: statements
7 /

8. If drivers are made by copy-paste, maybe we can understand them by clone detection

9. Clone detection issues
static int am79c961_probe(...) {
...
dev = alloc_etherdev(...);
if (!dev) { ... }
ret = platform_get_irq(pdev, 0);
if (ret < 0) { ... }
dev->irq = ret;
ret = register_netdev(dev);
if (ret == 0) {
return 0; }
free_netdev(dev);
static int ftmac100_probe(...) {
...
irq = platform_get_irq(pdev, 0);
if (irq < 0) return irq;
netdev = alloc_etherdev(...);
if (!netdev) { ... }
priv->irq = irq;
err = register_netdev(netdev);
if (err) { ... }
return 0;
free_netdev(netdev); }
drivers/net/ethernet/faraday/ftmac100.c
drivers/net/ethernet/amd/am79c961a.c
9 /

10. Drivers are not made of clones, but of genes
A Gene:
Motivated by device features and OS API
Examples of features:
NAPI
Packet segmentation
Checksumming
DMA support
Offloading engines
Set of possibly non-contiguous code fragments
Express the behavior of the feature
10 /

11. Notes about: Ethernet, MDIO, PHY
MDIO: Management Data Input Output
Ethernet
controller
MDIO bus
PHY
MDIO features:
Management Data Clock (MDC)
Bidirectional MDIO data (Ethernet frames)
Single Ethernet controller
Up to 32 PHYs
11 /

12. Example: Devices, drivers, Genes
Platform device entry point 1
Init. Memory mapped IO
Init. MDIO bus
Init. Interrupts
Init. Clock
orion_mdio_probe() MDIO bus (for PHY)
Platform device entry point 2
Connect to net_device support library
Init. Interrupts
Init. MAC address
Init. Ethtool
mvneta_probe() Ethernet controller
12 /

13. Evolution of (Ethernet) Genes
13 /

14. Gene therapy (replacing genes)
Port
Write
Maintain
Backport
Driver genome
Ease driver development
Copy-paste programming aid tools
14 /

15. Ongoing work Sequencing and mapping genes Currently manual.
Protocol mining?
Finding genes instances
Coccinelle!
Writing semantic patches automatically?
Organize genes
Feature oriented database of Genes.
15 /

16. Conclusion New way of understanding drivers: Genes!
Experiments on finding genes
Genes for memory mapped I/O
Potential of genes
16 /