[lkml]   [1999]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRE: Binary drivers
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 [] 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
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

> 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
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.


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

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.051 / U:7.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site