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..