[lkml]   [1998]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectWhat is accepted into the standard kernel sources ?
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

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

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

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