Linux driver project gets a full-time leader [LWN.net]

By Jake Edge
October 3, 2007

The Linux Driver Project (LDP) just got a big boost, courtesy of Novell and Greg Kroah-Hartman. The project was announced last January to much acclaim, but has languished since, buried under Kroah-Hartman's "day job" and Linux kernel development work. Now, he will be able to devote much more time to the project as his employer, Novell, has shifted his job responsibilities to work full-time on the LDP.

The original project announcement was released in conjunction with the Freedom HEC conference and was described by Kroah-Hartman as a "lame publicity stunt", because it just reiterated the standard Linux driver development model: with some hardware and some information, a driver for your device will be written. There was a new wrinkle, though; an arrangement worked out with the Linux Foundation to allow driver developers to sign non-disclosure agreements (NDAs) with hardware vendors to get access to documentation and other information about the device. NDAs for driver development are controversial in some quarters, but are often required by hardware vendors.

There are numerous benefits for Linux: the drivers will all be licensed under the GPL, will get merged into the mainline tree, and be available for all Linux users. Other free operating systems may be able to use the source to write drivers for their systems, as well. Kroah-Hartman notes that a surprising added benefit is for new kernel developers:

Another wonderful benefit that I never had imagined in the beginning is that we are now providing a way for developers who want to write something "real" to have a place to go. The biggest response I got from my first announcement was from developers wanting to help out. I had over 80 people sign up to help out as they wanted to be able to contribute to Linux, but did not previously know how to do so in a tangible manner. This project gives them a place where they can develop and maintain a real driver for the kernel community.

Now that he has time to devote to LDP, Kroah-Hartman has put together two mailing lists along with a wiki to track the project. There is a mailing list for each of the two main roles, developers and project managers. The role of a project manager will be to facilitate the development, making sure that the driver hacker has what they need to get the job done and keeping the company, for whom the driver is being written, informed of the status. In short, they will shepherd an individual driver in much the same way that Kroah-Hartman is coordinating the LDP as a whole.

In less than a week since the project restart, there are five driver projects up for grabs, including a "clean-up and get merged" project that would be suitable as a first driver for someone just starting out in Linux driver development. Project managers are lining up to take on the drivers as well. The numbers of volunteers have grown, but as Kroah-Hartman notes, publicity is something the project still needs:

We currently have over 200 people signed up to be a developer, so we doing quite well there. We also have over 25 people signed up to be a project manager, so I think we are good there too. What we do need the most help on right now is to find more companies that need our help. Spreading the word that this service is available and open to any company is the biggest importance I think at this time.

Already, there are drivers for many different kinds of devices in the pipeline:

[...] audio codec devices, USB timestamp devices, VOIP devices, video camera devices, lots of different types of data acquisition devices, as well as some custom bus interconnects and even some whole system-on-a-chip devices.

Kroah-Hartman plans to reconnect with various companies that contacted him since January, but fell by the wayside. As that happens and the word gets out about the project, there should be driver development projects suitable for a wide range of interests and various levels of kernel experience. By providing a self-contained project that is targeted at inclusion in the mainline, more developers will be exposed to that process, which should expand the ranks of kernel hackers.

Linux already supports more hardware than any operating system has before and the LDP will only extend that lead. There are huge benefits for Linux, the developers and project managers, the companies whose devices will be supported, as well as for distributors like Novell. There may be complaints about signing NDAs, but the drivers will be free, not obfuscated; once companies see how easy it is to get a high-quality driver into the kernel, they will certainly come back for more. This can only be a good thing for all free software systems, not just Linux.

(Log in to post comments)

NDAs

Posted Oct 7, 2007 0:32 UTC (Sun) by man_ls (guest, #15091) [Link]

The documentation necessary to build a device driver may be mixed with other things, not relevant to how the device works. For example, you might have electronics schematics, competition comparisons, or even future plans for the device. And the company might not want to devote the time needed to separate it. An NDA might specify that the developer may not divulge any information not relevant to the device driver.

NDAs

Posted Oct 13, 2007 12:03 UTC (Sat) by Duncan (guest, #6647) [Link]

That future plans clause is the one I've seen mentioned before in this
regard. In several hardware product areas (particularly embedded, think
cell phones and some of the individual components they contain), the
public lifetime of a product isn't much more than six months. This is
far too short a time to get a full driver written, start to finish, and
by the time it's out and stable, the product itself has long disappeared
and been replaced by new generations, perhaps not entirely different, but
enough different so adapting the drivers to match, then testing them,
takes yet another hardware generation, and the driver never /can/ catch
up with the software, even given reasonably decent support during 100% of
the public life of the product. That's especially the case considering
the kernel release cycle itself is 2-3 months, so even if development
started immediately and went without a hitch, it could be half the
product's publicly available life cycle before drivers are available in a
released kernel!

Enter these NDAs and developers willing to sign them; willing to work
with the company from long before the product is made public; from even
before product plans are finalized. This can be VERY competition
sensitive information, and the company is right to worry about it getting
into the wrong hands. A limited time NDA, expiring on most of the
technical data when the product goes public, but permanently covering
business plans and the like, even including stuff such as products that
never made the cut, for whatever reason, as that sort of info on the
process could be very damaging should it get into the competitor's hands,
can very well mean the difference in these cases between a working driver
available and in the released kernel at product release (meaning
development time of at least 90 days before that, time covered under NDA,
even if the drivers themselves are public), and one not available at all
during the actively available product lifetime.

Duncan