Fwd: Linux headed for disaster?

[Arun Sharma <adsharma@xxxxxxxxxxxxxxxxxxxxxxxxxxxx>]

I don't see this as a discussion for linux-india-general. But 
this message that just got posted to comp.os.linux.development.system
is bound to generate a flurry of postings.

Touches many topics - GPL, powers held by Linus et al, FreeBSD etc.

Watch the newsgroup for some interesting debate.

	-Arun

> From: KendallB@xxxxxxxxxxxxxxx (Kendall Bennett)
Newsgroups: comp.os.linux.development.apps,comp.os.linux.development.system
Subject: Linux headed for disaster?
Message-ID: <MPG.12b470dce8586acd9896b8@xxxxxxxxxxxxxxxx>
Date: Sun, 5 Dec 1999 12:55:10 -0600

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@xxxxxxxxxxxxx>
To:             	Kendall Bennett <KendallB@xxxxxxxxxxxxxxx>
Copies to:      	Alan Cox <alan@xxxxxxxxxxxxxxxxxxx>
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          | To reply via email, remove nospam from    |
| Director of Engineering  | the reply to email address. Do NOT send   |
| SciTech Software, Inc.   | unsolicited commercial email!             |
| 505 Wall Street          | ftp  : ftp.scitechsoft.com                |
| Chico, CA 95928, USA     | www  : http://www.scitechsoft.com         |
+----------------------------------------------------------------------+