From:   "Kendall Bennett" <KendallB@scitechsoft.com>
To:     linux-kernel@vger.rutgers.edu
Date:   Sun, 5 Dec 1999 12:53:18 -0800
Subject: Linux headed for disaster?

Hi All,

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/