Messages in this thread | | | From | Bret Indrelee <> | Subject | RE: Binary drivers | Date | Sun, 5 Dec 1999 20:37:19 -0600 |
| |
One thing that is clear to me is we should probably add an FAQ entry covering binary compatibility of modules and drivers to the lkml FAQ. Give a listing of things that currently prevent binary compatibility, and perhaps a short statement that anyone who wants this fixed should be willing to do the work required (i.e. submit code) to fix it.
This topic flares up fairly often. I caused it to flare up a couple of times while trying to understand the mindset of this mailing list, and I can think of a couple more instances since then.
Matthew Kirkwood [mailto:weejock@ferret.lmh.ox.ac.uk] wrote: > The Linux device driver interfaces (such as they are) are > fairly stable > indeed. The higher-level interfaces (for filesystems, for > example) are > a lot more mobile, but this isn't your issue.
You have GOT to be kidding!
The driver interface for Linux has changed for 2.0, 2.2 and based on what I've seen of 2.3 will change again for 2.4.
Every major version has found some reason to change the driver interface. Examples include but are not limited to: 1. The routine has changed from poll() to select() between 2.0 and 2.2. 2. The method for doing timeouts has changed between 2.0 and 2.2. 3. You no long use the same methods to copy between kernel and user between 2.0 and 2.2. 4. Parameters changed to almost all the device entry points between 2.0 and 2.2. 5. It used to be that you would just change the task state, now you have to use set_task_state() for 2.3 and later. 6. The way that PCI devices determine their memory or I/O window, and what element in the structure, changes between 2.2 and 2.3.
I'm sure there are more. I haven't even really investigated the 2.3 changes, I only stumbled across a few because of being on this list.
None of the stuff from Rubini's book compiles against 2.2. The book is so out of date because of the changes that it is almost useless. There are a couple of resources that talk about converting such as Alan Cox's article in Linux Magazine and Richard Gooch's summary of kernel changes. That doesn't change the fact that anyone coming into the kernel now (even when experienced with other versions of Unix) will have problems doing a device driver with just the documentation available.
Look at how much discussion there was recently of what ioremap() does. I'm still not sure I understand all the architechure-specific constraints.
BTW: I have (been forced because of lack of proper documentation to) read the sources. Most of them don't even bother to comment on assumptions made nor what the parameters to various routines are. I have also submitted a patch to the documentation which tried to take care of some of the basics which every PCI driver has to know.
Don't come back at me with 'Then fix it.' because I didn't create the problems that exist. That answer gets really old after about the fifth instance, especially when I didn't have anything to do with creating the problem.
> The fact is that stable kernels have a fairly static driver interface, > which is _almost always_ source-compatible, if not binary-compatible.
For the case of Linux, don't you mean _ALMOST NEVER_ in the above sentence?
> So there really is no disadvantage to driver writers who are > willing to > contribute source, as far as I can see.
Here are some possible disadvantages: 1. From the corporate management point of view, driver source makes it easier for a competitor to reverse engineer a product or create one with a hardware-compatible interface. This allows the competitor to come in with a cheaper product because they didn't have to do any of the original R&D to define the interface nor develope the software to drive it. This will delay or prevent some companies from supporting Linux. 2. I believe there are still products which depend on Trade Secrets rather than patents and copyrights to protect some of their intellectual property. There may be instances where people don't want to open source a driver because of this. Does anyone know if WinModems are an instance of this? 3. Possibility of increased support calls because someone changed the driver yet consider it so minor so as to not be worth mentioning. Customers do mislead (translation: lie) to technical support people all the time. This creates yet another unknown that the technical support staff has to deal with. 4. They don't want to go through the effort of getting a legal opinion on what happens should they mix their own license with open source. The GPL virus doesn't prevent someone from making things that they write (such as their driver source) non-GPL. Yet another source of Fear, Uncertainty, and Doubt for management.
Given a bit more thought, I could quite likely come up with more reasons.
I do not agree with all the reasons, but that doesn't mean that other people don't consider them valid. Some or all of them may prevent vendors from supporting Linux.
-Bret
------------------------------------------------------------- SBS Technologies, Connectivity Products ... solutions for real-time connectivity
Bret Indrelee, Engineer SBS Technologies, Inc., Connectivity Products 1284 Corporate Center Drive, St. Paul MN 55121 Direct: (651) 905-4731 Main: (651) 905-4700 Fax: (651) 905-4701 E-mail: bindrelee@sbs-cp.com http://www.sbs.com -------------------------------------------------------------
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |