Linux driver project gets a full-time leader
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:
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:
Already, there are drivers for many different kinds of devices in the pipeline:
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.
| Index entries for this article | |
|---|---|
| Kernel | Device drivers |
Posted Oct 4, 2007 5:52 UTC (Thu)
by eru (subscriber, #2753)
[Link] (1 responses)
Posted Oct 4, 2007 12:33 UTC (Thu)
by jengelh (guest, #33263)
[Link]
Posted Oct 4, 2007 19:50 UTC (Thu)
by iabervon (subscriber, #722)
[Link]
Posted Oct 5, 2007 12:55 UTC (Fri)
by addw (guest, #1771)
[Link] (2 responses)
Posted Oct 7, 2007 0:32 UTC (Sun)
by man_ls (guest, #15091)
[Link] (1 responses)
Posted Oct 13, 2007 12:03 UTC (Sat)
by Duncan (guest, #6647)
[Link]
Enter these NDAs and developers willing to sign them; willing to work
Duncan
This LDP abbreviation is also used for the Linux Documentation Project
(http://tldp.org/). As both projects are closely related to Linux, this will certainly cause confusion...
LDP Acronym conflict
That's TLDP, but yes.LDP Acronym conflict
It looks like the "great for new developer" one lasted under 38 minutes, but he may have a waiting list of developers for similar future projects, which should be forthcoming.Linux driver project gets a full-time leader
So how does an NDA sit with writing proper comments in device driver code, or even choosing nice descriptive variable and constant names ? A mark of good code is that someone can understand *why* it is doing things the way that it does - it seems to me that the purpose of an NDA is the exact opposite.NDAs
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
That future plans clause is the one I've seen mentioned before in this NDAs
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!
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.