Messages in this thread | | | From | Henrik Storner <> | Subject | What is accepted into the standard kernel sources ? | Date | Tue, 3 Feb 1998 17:37:44 +0100 (MET) |
| |
Forgive me for intruding on the technical discussions here, but I have a question which I think is best discussed in this forum. If I am mistaken, please let me know where to ask this.
What I am trying to figure out is: What requirements are there for having new drivers added to the standard Linux kernel sources ?
I am not thinking of the purely technical matters - obviously, the driver must have been through some testing and appear reasonably stable, it should not interfere with the rest of the kernel unless where necessary etc.
What I am thinking of is how much of the driver needs to be available in source-code form.
The reason I am asking is that the company I work for - Olicom, a manufacturer of various types of network equipment - recently developed a Linux driver for our Token-Ring network adapters. This driver builds upon a small platform-independent library we have written, that makes it possible to write an operating-system specific driver for the cards without having access to hardware specifications. The driver - the part that interfaces between the Linux kernel and the library - is released under GPL. The library itself is not available in source form, but could be included with the kernel sources, e.g. in the form of a uuencoded object file. (That is how we do it right now). When I approached Alan Cox and asked if it would be possible to include the driver in the upcoming 2.0.34 release, he rejected it as soon as he heard that a binary module was included, and needed for the driver to work.
Now, whether or not the Olicom driver is included with the standard kernel sources does not bother me a whole lot - if necessary, we will just let people download the patch from our web servers. However, looking at the 2.1.84 sources it seems that some drivers already in the standard kernel do include binary-like modules (usually, firmware of some sort) - most often, SCSI-drivers and drivers for multi-port serial cards. I suppose that these kind of hardware devices will not work without the binary firmware, just like the Olicom driver will not work without the binary library.
So is there a clear distinction between the kind of binary modules that are accepted in the kernel sources, and those that are not ? Personally, I cannot see the big, conceptual difference between a binary module that contains "firmware", and a binary module that contains the equivalent of firmware, but is executed by the host CPU rather than some embedded processor.
In a wider perspective, a hardware vendor who wants to support Linux currently has three options:
1) Release hardware specs and let someone write a driver. 2) Write a driver himself and release it in binary form only. 3) Provide an API for dealing with the hardware, and have someone develop a driver based on this API (the "Olicom" way).
(1) is how it has usually been done so far. (2) is unacceptable to many Linux users, as there is no control at all over what the driver does; from the hardware vendors point of view, it also removes the possibility of Linux users suggesting improvements and changes to the driver.
In my opinion, (3) is a workable compromise between the two (but obviously, I am biased). As I see it, both sides would benefit from such an arrangement - the Linux users would have more hardware to choose from when building a Linux system, and the hardware vendors would be able to offer their products for use on a very popular platform.
I've always thought of the Linux community to be rather pragmatic - the "if it's useful and doesn't bother anything else, let us have it" approach. So I hope this can generate a useful debate, and is not shot down immediately with a "we want full source, or nothing" statement.
But even if you are not quite as pragmatic as I thought, Linux is still a beautiful OS.
-- Henrik Storner <storner@image.dk> / <hst@olicom.dk>
| |