Novell Makes Linux Driver Project a Reality

apokryphos writes "Novell have relaunched the Linux Driver Project by dedicating well-known kernel developer Greg KH to work on the project full-time. Greg KH writes: 'My employer, Novell, has modified my position to now allow me to work full time on this project. Namely getting more new Linux kernel drivers written, for free, for any company that so desires. And to help manage all of the developers and project managers who want to help out...They really care about helping make Linux support as many devices as possible, with fully open-source drivers.'"

Comments

Re:Cool

[deek]

I'm not sure how much just one developer can do, but props to Novell nonetheless.

Never fear, because he's not doing all the coding himself. According to the link in the article, he's had over 100 volunteers to help him out. If he's good at managing them, then 100 talented coders could certainly make a large impact!

Re:Still not the Right(TM) way

[Eivind Eklund]

Having worked both directly with hardware developers (as an embedded systems developer) and with kernel development, this is not quite that clear to me. In some cases, the hardware knowledge side is the most important; in others, the kernel side. Mostly, the kernel side of things is harder to learn than the hardware side, though, so the kernel development skills is the important side. Also, kernel developers often have more experience with working with different kinds of hardware, so they will know how to trick around the particular piece.

And, importantly: For a LOT of the hardware on the market, what's important is the chipset used, not wiring around it. And the "hardware manufacturer" has often only done the wiring.

Eivind.

not the case

[free space]

If that is indeed what worries the original poster then he can res assured, from the project's FAQ:

Q: How are you going to write a GPL driver by signing an NDA? Is it going to require a binary blob or some other way of obfuscating the code?

A: No, not at all. I have written many drivers after signing NDAs with companies. They are usually signed either to keep information about the device private until it is announced at a specific date, or to just keep the actual specification documents from being released to the public directly. All code created by this NDA program is to be released under the GPL for inclusion in the main kernel tree, nothing will be obfuscated at all.

Re:not the case

[mystran]

Having written one or two drivers for a completely irrelevant toy operating system of mine (making me just marginally less incompetent to comment on this thread), it is very helpful to have datasheets that actually describes the operation of a given device, instead of just something like a list of it's registers and their meaning. Even descriptions of sequences of commands required are not always helpful without understanding the internal workings of the device. The resulting code ofcourse has to take all relevant device details into account, but the code itself is typically not sufficient to figure out anything beyond what the original code has at least attempted to take into consideration, if even that (ofcourse any sample code is invaluable when trying to decipher datasheets but that's another issue).

So based on what little I understand about the whole subject, I'd say letting somebody develop a driver under NDA and just releasing the driver source instead of all the documentation is likely to keep a LOT more details about the device essentially secret, even if the code itself was pretty decently commented with remarks about the particular implementation (assuming ofcourse that said internal documetation isn't duplicated in the comments).

Ofcourse that DOES have the effect that anybody willing to improve the driver functionaly in regards to the device would need the same documents under NDA (or reverse-engineer the relevant details, which might be easier with a working driver to tweak), but at least a source driver let's the kernel developers deal with things like driver API changes internally. Say, you want to change the protocol by which drivers reserve IO resources because you've found a new, totally fair way to do that. Now, with binary drivers you can either break the drivers or implement workaround wrappers. Source drivers, you can simply change the driver code yourself without having a clue what the driver actually does. :)