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/