There have been discussions in recent months about why Linux does not
support binary portable drivers, such that binary drivers from one
Linux kernel version will work with future Linux kernel versions
without needing to be re-compiled.
Every single problem that has been mentioned as reasons not to
implment Binary Portable modules for the Linux kernel is solvable. In
fact there are *lots* of incredibly sound reasons for why the Linux
kernel should be re-worked to support binary loadable modules that
are portable between kernel versions, *even* for Open Source drivers,
some of which are:
1. A later version of a kernel may well have introduced new bugs
into a previously stable driver. Solving this problem currently
requires the user to revert back to an older kernel revision. Doing
so may not be desireable because the new kernel version may have
updates and fixes that are desired. With binary portable modules, the
module a previous kernel that did work could be used in place without
problems (ie: it is expected to work if unless there is an interface
change).
2. Binary portability requires more solid and clearly defined
interfaces between the kernel internals and the modules themselves.
By requiring that there be a clear separation or 'firewall' between
drivers and the kernel internals, you can more easily avoid the
classic problems of coupling where changes in some other part of the
code affect other code that should not be affected. Specifically it
makes it impossible for a driver to implement a 'quick hack' solution
by accessing the internals of some other driver or the kenerl
directly. However the *only* way to enforce this is to design device
type specific binary API's, and *require* that the only way a device
driver can talk to the kernel is via these API's.
3. Binary portability means much less regression testing is required
for new kernel versions. If the driver itself does not get re-
compiled, it does not need to be thoroughly re-tested. If the case of
the Linux monolithic kernel approach, every driver is compiled into
each new kernel version. How do you *really* know that a driver is
functioning properly when a final release of 2.2.100 is made, unless
*every* single device that is supported is properly tested with that
particular version?
A clear case in point in my book in the hardware compatibility as
reported by Red Hat on their web site. Go to the Red Hat web site and
check out the hardware compatibility list for network adapters. Red
Hat has the concept of 'Tier 1', 'Tier 2' and 'Tier 3' supported
hardware. Their definitions for this are:
---- Cut Here ---
"Tier 1 Supported Hardware
Tier 1 Supported Hardware is hardware that the Linux kernel can
detect and use. It is known to be reliable in-house and in the field.
Users who have purchased the Official Red Hat Linux 6.1/Intel boxed
set can expect a reasonable level of support when installing the
software on these hardware items."
"Tier 2 Supported Hardware
Tier 2 Supported Hardware is hardware that should be detected and
usable with the Linux kernel. However, some users have reported
problems with some versions of this hardware, or
with the hardwares interaction with other hardware.
Official Red Hat Linux 6.1/Intel boxed set owners can expect
installation support for this hardware, but it will be limited to:
. Providing information about which driver to use, install-time
driver options, and how to enter them into either the installation
program or /etc/conf.modules.
. Determining whether Linux is recognizing the hardware."
"Tier 3 (Compatible, but Unsupported Hardware)
Hardware listed as Tier 3 is mostly compatible, should be detected
and work with the Linux kernel on certain setups. The drivers for
this hardware may be experimental, or the hardware
may be problematic to work with.
Owners of the Official Red Hat Linux 6.1/Intel boxed set can expect
information on which included drivers to use with this hardware and
determining if Linux recognizes the hardware.
Drivers for this category are not always available from Red Hat, and
no support for third party drivers will occur."
---- Cut Here ---
Now in their list of supported adapters, they have only '5' families
of network adapters that are listed as Tier one, and some of those
families do not include popular cards (such as the 3Com 3c905B
EtherExpress XL PCI boards). In particular note the lack of *any*
NE2000 compatible adapters in this list.
Now look at the Tier 2 list. This list is rather larger, but surely
more of the adpaters in this list *should* be working better, since
they have been around for some time and hence the drivers *should*
have stabilised by now? I am sure Red Hat would not list hardware as
Tier 2 unless "some users have reported problems with some versions
of this hardware, or with the hardwares interaction with other
hardware".
More important is the fact that NE2000 adapters are listed as Tier 2
supported. In actual fact they don't work very well at all. We tried
using a variant of Red Hat linux 6.1 on a system with two NE2000 ISA
network adapters for a firewall. Guess what? It didn't work. We
replaced it with two PCI 3Com 3c905B adapters and it is now working,
but it doesn't make me feel confident when these adapaters are also
not listed as supported by Red Hat. What is worse is I know that the
NE2000's have worked perfectly in the past with the Linux 2.0.x
kernel, as we originally had a variant of Red Hat 5.2 on the same
machine running as a firewall and it worked fine.
Which brings me back to the original point of my email. It would
appear to me that unless Linux implemented a more clearly defined,
binary portable driver mechanism, compatibility problems will
continually creep in over time, plaguing the operating system with
incompatibilities. Unless these problems are solved, and device
driver conformance tests implemented, Linux is headed for disaster
further down the track.
Constrast this again with FreeBSD whose development methodology
actively supports binary portable kernel modules. Perhaps now it
makes more sense why FreeBSD is considered more stable than Linux and
that so many web servers run FreeBSD and not Linux. FreeBSD does not
support as much hardware, but for what it does support, it is more
stable.
The problem is that the *reasons* why the powers that be (Alan Cox
and Linus Torvalds) do not want to implement binary portable drivers
for the Linux kernel, are *not* based on sound reasoning.
Specifically note the following correspondance between myself, Linus
and Alan from about a month ago:
---- Cut Here ---
Date sent: Thu, 11 Nov 1999 17:00:56 -0800 (PST)
From: Linus Torvalds <torvalds@transmeta.com>
To: Kendall Bennett <KendallB@scitechsoft.com>
Copies to: Alan Cox <alan@lxorguk.ukuu.org.uk>
Subject: Re: Binary loadable drivers in Linux?
On Thu, 11 Nov 1999, Kendall Bennett wrote:
> > My opinion is that you should just continue to do it from user
> > land.
>
> The problem is that the things we need to do *cant* be done from
> user land. This specifically include the need to hook an interrupt
> handler for DMA operations, which are very important for high
> performance 3D graphics on Linux (and obviously for sound
> drivers).
Well, maybe you should be looking at Solaris/x86 then?
I'm not all that interested in trying to help binary-only drivers,
when people like 3dfx are opening up their specs and their libraries
to the open source community. Why would I go to the extra work to
help people who aren't even willing to help me?
Quid pro quo. That's what the license is all about. I =allow= binary
only drivers, but that is very different from =supporting= them.
Linus
---- Cut Here ---
The *reason* binary portable drivers are not implemented in Linux, is
because Linus and Alan are wielding the power of Linux to *force*
hardware vendors to implement Open Source device drivers. IMHO this
is just as bad as Microsoft using their monopoly power to force
vendors to ship Windows on their PC's.
Surely true Open Source advocates would realise that companies will
embrace Open Source for their products *if* it makes sense for them
to do so? Eric S. Raymond has mentioned numerous times in his musing
on Open Source software that Open Source is not suitable for every
company and every software project. So why should vendors be *forced*
to release information about their hardware just because Linus and
Alan feel this is necessary in order to force Open Source on the rest
of the world?
The specific example Linus used in his response above was 3dfx. 3dfx
is opening up their information because it makes sense for them to do
so, not because they are being forced to do so. The information is
being used to implement XFree86 drivers, which are *not* GPL'ed, so
obviously it isn't a GPL requirement that is making them open up
their specifications. XFree86 is under the X/MIT license which
specifically allows for use in commercial projects (same license used
by FreeBSD). More importantly XFree86 4.0 is designed around the
concept of user land binary portable modules, specifically to solve
the above mentioned compatibility problems. On top of this, there are
commercial X-server vendors for Linux that 3dfx could have had
implement their drivers, and continued to keep them closed source.
They didn't do that because they realised it is cheaper and makes
more sense to have those drivers be Open Source rather than closed
source.
Lots of stuff available for Linux outside of the Linux kernel is not
Open Source. A lot of stuff is. The stuff that is, is Open Source
because it makes sense for it to be Open Source, not because the
developers were forced to make it Open Source. Open Source software
will be successful because of the power that opening the source code
provides. The power that 'With enough eyes, all bugs are shallow' as
Linus once said. Has Linus forgotten the reasons why Linux is where
it is today? Instead he appears content to wield the power of
dictator over the Linux kernel sources to force vendors to do things
his way.
Regards,
+---------------------------------------------------------------+
| SciTech Software - Building Truly Plug'n'Play Software! |
+---------------------------------------------------------------+
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
+---------------------------------------------------------------+
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/