lkml.org 
[lkml]   [1998]   [Feb]   [3]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What is accepted into the standard kernel sources ?
  From: Henrik Storner <storner@image.dk>
Date: Tue, 3 Feb 1998 17:37:44 +0100 (MET)

[snip]

What I am trying to figure out is: What requirements are there for
having new drivers added to the standard Linux kernel sources ?

The requirements are whatever Linus Torvalds is willing to accept, but I've
previously had some discussions in this area and will give a summary here.

[snip]

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.

Linus and I discussed this at length regarding the Mylex/BusLogic FlashPoint
SCSI Host Adapters. The FlashPoint SCCB Manager library code runs on the host
CPU essentially in place of firmware running on an onboard processor as with
the MultiMaster boards. Any software that runs on the host CPU is *required*
to be in source form; binary is considered perfectly acceptable for firmware
that is downloaded to a board, though obviously source for that would be nice
too. One of the key conceptual differences here is that at least in theory, a
driver in source form with downloaded binary firmware can execute on any
hardware-compatible platform Linux runs on, or can be made to do so. The
binary library module would have to be provided by your company for each Linux
platform to be supported, and that does make a conceptual difference.

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

Or:

4) Recognize that the library implementation does not really need to be kept
secret, and provide it in source form. Mylex/BusLogic took this approach
and the FlashPoint boards are now quite popular among Linux users. Despite
dire predictions of a few people internally, the world has not collapsed due
to their having done so.

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

My personal approach to the similar situation with the FlashPoint was that for
option (4), I would volunteer to write the driver primarily as a service to the
Linux community, and the manufacturer just happens to benefit greatly as well.
I consider option (3) to be inappropriate as a *volunteer* effort, especially
since it can never be made part of the standard kernel sources. Mylex did
consider option (3) for FlashPoint, and I would probably have written such a
driver as a "work for hire" if necessary, but I would have considered any
ongoing support and maintenance to be their ultimate responsibility. Option
(3) is certainly preferable to option (2), since it does allow for some outside
maintenance, but I still view it as your company's responsibility to be or hire
the "someone" in that case.

That's just my personal perspective on the tradeoffs. Others might feel
differently; I expect quite a lot from companies who are going to benefit from
my volunteer Linux work.

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.

Indeed, there is quite a bit of pragmatism, and no doubt there will be people
willing to use a binary only or hybrid source/binary driver if that's what you
make available. But no such solution will ever be the preferred approach, nor
will it ever be part of the standard kernel, unless Linus changes his views
drastically in this area.

Leonard

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