Driver Kits

From openSUSE

A common challenge of Linux distributions is getting support for hardware that does not work with the distribution yet.

For SUSE Linux Enterprise Novell is providing the driver process infrastructure to hardware partners since 2006 and Fedora is looking at this in Project Awesome.

The openSUSE community has expressed a strong desire for improved hardware support. This article first gives some background and then looks at how we can enable our community to help ourselves with hardware support using the openSUSE build server. It also looks at what we need to make improved hardware support really easy to use.

Background: distribution models of hardware vendors, kernel community and distributions

Component Vendors

• continuously add support for the most recent chipset release
• release snapshots of that evolving code to specific products and systems
• aim at being backwards compatible, though
• ususaly don't test backwards compatibility, thus

In case of a driver bug ('fix the driver')

• fix the issue in the current driver
• add the affected chipset releases / products to the ones for which this driver snapshot is reccomended

System Vendors

• get driver recommendations from component vendors
• test wether these drivers work
• if it doesn't, make the component vendor 'fix the driver' (which see)
• release the system with these drivers
• expect customers to run these driver snapshots (and no later ones)
• usually reccomend to stay with the driver that works until explicitely being told to update

In case of a driver bug ('fix the driver')

• get a new driver from the component vendor
• get it to the customer
• distribute it to all affected systems

Kernel Community

• reccommend to host the driver in the upstream kernel
• one driver fits all due to broad testing

In case of a driver bug ('fix the driver')

• fix it in the current kernel

Distributions

• pick some kernel release (vanilla)
• add their distro specific patches and backports from the kernel (straciatella)
• get it broadly tested before distro release
• only add security fixes to not break current configurations
• new hardware support only with the next distro release

In case of a driver bug ('fix the driver'):

• create a minimally intrusive fix for the issue in the old code (e.g. backport selected patches) to not affect other systems
• retest
• distribute with the kernel to all systems

The challenge: get a current driver to a selected old system

Distributions, Kernel Community and Hardware Vendors seem to work in incompatible ways. The major gap is that hardware vendors ship driver snapshots of different points in time to respective selected systems, while the Kernel and distros ship the same driver snapshot to all systems.

Even once there is a method to selectively distribute drivers, there remains the challenge to automatically select the right one.

The Solution: "driver kits" and a driver tool

Conceptually, a "Driver Kit" is the driver snapshots that you are recommended to use on a system or for a component.

You can think of it as a disk containing the drivers needed for this machine. Actually there may be several ones, like the one you got from your system vendor, and then one you got from a component vendor. They could just be entries in a database like drivertools.org, or a physical add-on product with an online repo, as SUSE has it.

Key is: a driver kit is the drivers recommended for a product.

Providing The Right Drivers for a system

"Providing the right driver" can mean things as different as providing them at all, as source; telling how to find the right ones amongst different snapshots in time; having possibly more than the right ones installed and autoprobing which ones to actually load.

This section will look at each of them and tell how to do it or at least how to possibly do it.

Provide precompiled drivers for a chipset

1. create a project for the chipset
2. put in KMP source packages, one for each snapshot of the driver
3. build them to each target distro you'd like to see them available for

Select specific driver snapshots for a system (aka: make a driver kit)

1. create a project for the system, named after the system
2. aggregate the drivers for this specific system from the driver projects

These driver kits can simply be connected to the system by adding them as installation source. The driver KMPs that match the system should then be autoinstalled via modalias package dependencies.

Automatically connect a system to the right driver kits

This is ongoing research.

Fragments available:

• since kernel 2.6.23 a module can also match DMI/SMBIOS information
• for SUSE, driver kits as a whole could Supplement: such modaliases and an installer could automatically match the driver ktis that fit the system by such patterns
• not sure wether libzypp allready supports installation source preferences to override package versions. This is needed to be able to specify an _older_ driver version for a system.

In presence of KMPs from a single driver kit, load the right modules

If only the KMPs proposed for this system are installed, then depmod will use it's preferences mechanism to select the drivers from the weak-updates subdir over those from the kernel.

support several system with a single initrd

If a single initrd is needed that works on different systems types that need different driver ktis, then 'the right drivers' need to be loaded by a lightweight mechanism.

This is ongoing research.

Fragments available:

• a fully dynamic mechanism needs to support symbol dependencies, blacklisting, modalias matching and precedence of one driver kit over another. this is equivalent to a full package dependency solver like the one in libzypp, yum, smart or apt-rpm.
• a lightweight mechanism fits a selected range of machines. It matches one of them by dmi:- and other modalias information. It then loads exactly the modules supporting this configuration. Adding a new machine type to the site means updating the initrd with the exact modalias fingerprint extracted from the machine.

outlook

This is ongoing research.

Any fully dynamic solution, supporting to add hardware components that need drivers not installed yet, possibly dynamically, before reboot or during suspend (horrors ;) needs a full dependency solver at least in depmod, if not in modprobe: driver kits can override drivers, split them, override them with an older version, replace a module in the middle of a stack of modules and drivers can even conflict. modules depend on each other (via the symbols) and they are connected to the system (via modalias).

For this analysis doesn't matter wether the driver kits are shipped the way Novell currently is shipping them or wether the drivers are hosted somehow somewhere, free-format, and the concept of driver kits is silently embedded in a driver database that maps drivers to the contexts in which they are to be used: the complexity is in the problem itself.

Any drivertool that aims at supporting autodetection of the right drivers for a system amongst all available drivers matter of factly is a full dependency solver.

If we seperate the selection of the candidate driver kits and of the driver packages from the loading of the drivers, then the system management layer needs to be invoked dynamically (HAL), check wether the right drivers are on the system yet, do the necessary installations, run depmod and then signal the system to load the module that now is available. That is a possible solution. It is minimally intrusive to the current depmod/modprobe --- yet it is very complex and involves smooth interaction of several different layers (kernel->hal->system management->packge solver->hal->kernel...

Alternatively: Does the kernel community see the similarity of how chipset makers manage their code and how the kernel community is managing theirs? Would the kernel community accept to extend modprobe depmod such that backporting and distributing a current upstream driver to a frozen distro kernel becomes a smooth experience? And can there be a speedy lightweight dependency solver at the core of the new driver tool (that possibly also can be used as dependency solver higher up in the stack?)

If the kernel community sees the similarity of the hardware vendor's release model and the kernel community model and allows