"Yes, that's right, the Linux kernel community is offering all companies free Linux driver development. No longer do you have to suffer through all of the different examples in the Linux Device Driver Kit, or pick through the thousands of example drivers in the Linux kernel source tree trying to determine which one is the closest to what you need to do. All that is needed is some kind of specification that describes how your device works, or the email address of an engineer that is willing to answer questions every once in a while. A few sample devices might be good to have so that debugging doesn't have to be done by email, but if necessary, that can be done."
To view parent comment, click here.
To read all comments associated with this story, please click here.
Member since:2005-07-06
The spec might not be available as a separate document but be part of vendor internal documentation describing other details of the device.
Exactly, and it's easier to just give the developer access to those documents, rather than having someone write a spec. Or have him go through the internal documentation, removing the parts the company don't want public. It's both a costly process for the company. And it's likely the person(s) responsible will err on the caseous side and remove too much, making the spec lacking.
Using a NDA makes more sense not only from a busness and economical point of view, but also from an engineering viepoint.
Edited 2007-01-30 19:26
Member since:2005-07-08
What documents? I agree with you in principle, but in practice these hardware vendors have to be so quick to market that there isn't usually ANY natural language documentation.
As Linus has said many times, the source code is the only valid documentation. Any print documentation is inherently out-of-date and/or inaccurate--at least in the commodity space.
That's why many hardware vendors will choose the part of the offer where they supply an engineer's email address. "Well, I don't know how that register works, but I do know that we set it to 0xFFFFFFFF in our Windows driver."
Edited 2007-01-30 22:03
Member since:2005-07-13
A developer under NDA could be given access to the whole documentation and only the information necessary for interfacing with the device will end up in the driver code.
IANAL, but I suspect that the NDA situation will still have to be handled via a clean-room type of scenario. A developer under NDA (likely working under the OSDL/Linux Foundation) may be given access to engineering information necessary to create the driver, but will probably have to create a non-infringing spec that the kernel devs will use for coding against.
There's too big a liability for kernel devs coding under NDA's since there's an inherent risk of tainted code inadvertently getting into the kernel, and it could ultimately handicap the kernel devs on potential future code contributions they could make. It's bad enough that MS is making ambiguous claims about MS-owned "ip" in the linux kernel, it would be very dangerous for commercial companies to have a legally valid paper trail backing up similar accusations. Even companies like IBM and HP keep their OSS and proprietary developers separate to prevent the risk of code taint in either direction.
Letting an independent party under a binding NDA have access to the necessary information in order to produce a vendor-approved design spec for the non-NDA'd kernel devs provides necessary legal protection for the devs and the kernel in general. This is also important for the vendors because it not only allows them to maintain control over the degree of information publically released, but can help ensure they themselves remain in compliance with licensing agreements, since in many cases vendors cross-license technology from other companies and are obligated to prevent it's public disclosure.
I know things like that may not fly as well with the free-software side that would want full disclosure on every aspect of the hardware, which I agree would be ideal, but I think it's a reasonable compromise that respects the legal concerns vendors may have. Of course, that whole process is not much different than what they do now with reverse-engineering, but at least it should cut down the development time considerably, particularly if they have access to back-channels at the vendor for troubleshooting support.
But like I said, IANAL and maybe they've worked things out differently.
On a side note, I also think that, to a certain extent at least, it may help the business case for vendors that may otherwise be willing to support linux but unable to invest in any resources to do so. It's very difficult to build business cases for resource allocation when you have absolutely no form of metrics or potential market to even ballpark an ROI, that's just business reality. And there are already precedents for vendors that have basically out-sourced linux support to community developers, unable to justify the business case internally with the beancounters.
Personally I think this is a good thing, though I'm taking a cautious wait-and-see attitude before becoming overly optimistic. They've eliminated a barrier for entry that may or may not have existed for many vendors, we just need to see if those vendors will step up now.
Just my 2c...
Member since:
2005-07-07
If a manufacturer don't want to give out its specs, even if the kernel guy who writes the driver doesn't give them out, the open source driver will be there for anyone to look
The spec might not be available as a separate document but be part of vendor internal documentation describing other details of the device.
A developer under NDA could be given access to the whole documentation and only the information necessary for interfacing with the device will end up in the driver code.