Driver Life Cycle

[ This is a DRAFT version, under construction ]

Opening up the specification for the hardware component is the first right step towards Linux support for that hardware. If the hardware is readily available there is a high chance that somebody in the community will write a driver. But if it is not, then the hardware vendor has two choices. Provide the pre-production version of the hardware to key community members, or write the driver and release it often to the community. In either case its a iterative process of driver development which follows the community mantra of 'release early, release often'. Eventually when the driver is deemed ready by the core community members, it is merged into the Linus Torvalds kernel source tree. This driver will then be officially made available in roughly about 10 to 15 weeks once the new version of the kernel is released.

Community distributions like Fedora, Ubuntu tend to quickly pick the new kernel version and make them available for their latest release through their repositories. Sometimes the same kernel version is also picked for their next major release. In either case the driver is available to the end users fairly quickly after the kernel release.

Enterprise distribution on the other hand follow a different model. Enterprise distributions fork off a kernel version for their release train. For example RHEL4 is based off 2.6.9 kernel, SLES9 is based off 2.6.5 kernel. They cannot afford to move to the latest kernel release because of their commitment to customers and software and hardware vendor to keep the kernel API and ABI stable. Given this constraint enterprise distribution carefully backport the driver ensuring API/ABI stability. The driver becomes available to the enterprise customer through the next release in roughly about 6 months.

if everything goes well the driver reaches the hands of the end user in approximately 9 months. But not always everything goes smooth. Its hard to predict the exact time the driver is merged upstream.

Many factors govern the timeliness. Any driver that requires added functionality supported in the generic kernel code, invariably carries the risk of delay. The community has to be convinced that the new kernel functionality requested is generic enough to be useful for many other purpose.

Even where the driver is self sustainable, component vendors due to lack of open-source awareness tend to neglect the 'release early, release often' mantra. Consequently they end up creating a large code base that is hard for the community to understand and merge.

Sometimes the component vendor fear the loss of market advantage if they discuss their new hardware publicly. They hence delay opening up their specification consequently adding further delay to the schedule.

Less often, even when all the rules are followed meticulously the driver may delay since some key members of the community may get occupied with other pressing issues, hence may not have had time to review and comment on the code.

Distributions sometime slip their schedules too. Even a major bug can cause schedule delay.

System integrators identify the distribution releases to support their new system based on the distribution GA dates and the system GA dates. Any slip in the release can inadvertently cause support for that release to be dropped for the system. This can cause the system to GA without support for some of its components by the enterprise release.

The key point is, even with meticulously planning; support for some components can miss due to uncontrollable reasons.

A asynchronous device driver delivery service becomes a necessity to alleviate the problem. Bear in mind that this service is only needed as a stop-gap for drivers until the driver is available in the next release.

Some enterprise distributions offer asynchronous driver delivery service. However the service is only available for the recent releases, leaving a big gap for older releases. The deployment of the drivers provided through the asynchronous driver service, requires different process and tools depending upon the distribution.

To fill some of the gaps, system integrators and component vendors have invented their own asynchronous driver delivery service. This has lead to proliferation of vast amount of incompatible technologies for no apparent value to the end user.

The Device Driver Backport Workgroup recognizes the existence of issues towards delivering device driver currency to our end users. We envision the need for a single solution that works across the board for all major distributions. Towards this we have identified the following gaps. (1) Redundant work and overhead for each distribution towards driver backport. (2) Non-existence of a distribution agnostic build and packaging mechanism for drivers. (3) Non-existence of a distribution agnostic tools to deliver drivers and their co-requisites to the end users.

to be continued..