lkml.org 
[lkml]   [1998]   [Feb]   [4]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: What is accepted into the standard kernel sources ?
On Tue, 3 Feb 1998, Henrik Storner wrote:
> What I am trying to figure out is: What requirements are there for
> having new drivers added to the standard Linux kernel sources ?
[...]
> What I am thinking of is how much of the driver needs to be available
> in source-code form.

Everything that you wish to be in the kernel. Nothing more, nothing less.
This isn't quite clear: not because it isn't a part of the kernel on a
technical level, but because it is a driver. Drivers are commonly available
outside of the kernel, to be built sepperately. They don't draw off of code
in the kernel. The "original" kernel was not an ageragate, it was a
modifacation of GPLed code (minix). All versions _of the "pure" kernel,
without drivers_ since have been modifacations of that. But the drivers are
generaly copies of works that also exist (and are maintained) sepperatly
from the kernel. So you can view the kernel "proper" as one component, and
each of the drivers sepperatly as other components, so the whole is an
ageragate. So a binary-only module could be in the offical tree, as it can
have sepperate terms.

This is purely my opnion, based on what I know of copyright law and the
GPL. However, whether legally required to not included it, or allowed to, I
don't think he would allow in in the offical tree. I would agree with him.
Linux is all about the power of free software, and free it should remain.

> 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.
And your costmers thank you for it. They would do so more if they could see
the source, and improve it, and port it to other OSes, and other processors
(more importantly, as new OSes shouldn't require new work.)

> 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.
Interesting design move. Interesting, but mostly useless. I should think
that having #ifdef LINUX, #ifdef WIN95, etc, would do just fine, and be a
lot speeder and simpler.

> The driver - the part that interfaces between the
> Linux kernel and the library - is released under GPL.
Definatly a good thing.

> 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).
The thing is that I don't see any binary-only files in the tree, and I'm not
too shure how well it would mess with the GPL (of the whole tree). I am how
shure it would mix with Linux's ideology and mission of freedom. It
wouldn't mix.

> 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.
As well he should have IMnsHO. Linux is copylefted freeware. Your module
would violate that.

> 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.
A fine pratice (I would suguest also including it on the drivers diskette,
if there is one. I would be surprised if it wouldn't fit.)

> 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.
Cyclades has code to deal with the firmware (in case it hasn't been loaded),
and many of the sound drivers can load firmware. QLogic ISP bord firmware
is the only one that I found... that surprises me greatly.

> 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.
The way I see it is this: all code that is to execute by the machine that
linux is compiled for, and all code that is involved in its compilation.

> 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.
Hmm... I can. Linux isn't designed to be run on that 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.
2) Write a driver himself and relese it...
a) GPLed
b) /w Source
c) Binary-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 a nice option. 2a is the prefered method: it can be in the kernel
proper, users have complete fredom, and the vendor dosn't have to worry
about upgrading the driver to newer kernels. 2b is nearly as good, but that
way you can forbid, for example, modification for use with another vendor's
products. 2c I see little benifit of: every minor detail has to be handled
by the vendor, as users can't fix errors in the driver.

> (1) is how it has usually been done so far.
Because it is generaly the nicest method for all involved: the users can do
their own writing of the driver, and associated matinance. The vendor
dosn't have to spend any resorces on the driver (the specs should already be
in publishable form, for your own team (which assumadly wrote win95 and
winNT drivers)).

> (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.
But under 2b or 2c, the vendor dosn't have to worry about enhancments, the
users can enhance themselves. Under 2c, however, all driver enhancements
must be done by the vendor. (Under 3, only most of it needs to be done by
the vendor).

> 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.
All of the options do that. IMHO, the best arangment might be 2b: the
source is relesed, under GPL plus the stipulation that the driver cannot be
modified for the purpose of using it with another vendors problems, and make
it clear that the driver is a "gift": you don't expect to relese other
versions unless there is new hardware, and you don't want feedback on it.

> But even if you are not quite as pragmatic as I thought, Linux is
> still a beautiful OS.
It is a beautiful OS because:
1) We have ideals that we try to hold to.
2) We keep our code clean (we can't if we don't have the source).
3) We are pragmatic.
In more or less that order.

-=- James Mastros
--
"I'd feel worse if it was the first time. I'd feel better if it was
the last."
-=- "(from some Niven book, doubtless not original there)"
(qtd. by Chris Smith)

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu

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