> 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.
What for ? Why to solve a lot of problems to got only additional problems ?
> 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).
You can recompile old driver if changes were not significant (that is: in
99% cases) or you should rework driver due deep changes in kernel anyway.
Just like you can not use binary driver from Windows95 in WindowsNT you
can not use source code for linux 1.2.13 driver in linux 2.2.14. You CAN
expect from driver for 2.2.0 to be compileable and useable in 2.2.14.
And it's usually the case. Not always -- just like Windows NT SP4 can break
drivers compatibility sometimes.
So 1. is not reason to support portable binary drivers. Linux's source
drivers works just as well.
> 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.
On other hand this WILL require to use uneeficient code (take look on
spinlocks, for example) in drivers. EVEN if driver is binary only Windows95
driver it STILL can alter other driver to fix error there (we cooked such
drivers here to workaround some Windows95 problem). So binary drivers WILL NOT
make life easier. Published API is good and kkeping driver from using kernel
inetrnals are good but binary drivers WILL NOT help here.
So to solve 2. you need solid API and control and binary drivers DO NOT HELP
here. This problem is orthogonal to availability of portable binary drivers.
> 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.
Not at all. Driver does not live in vacuum. It interacts with system. And
binary drivers will not help here (see above).
> 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?
How you can *really* know if your driver can be used with Windows98 if it
was fine with Windows95 ? Answer: you can not. Even if theory interface is
the same on practice you need deep rework to make in working with Windows98
(been there, done that).
So once more it's not reason to make binary portable drivers possible.
You need regression testing with any kernel version with or without protable
binary drivers.
> 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.
And guess what ? Binary compatibility between versions will be ZERO help.
ABSOLUTELY zero. NE2000 are not there NOT since driver can not be used across
different kernel versions -- it can (with recompilation, obviously). The
problem is that driver is not stable enough to include such cards as
"Tier one".
> 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?
How long device is available is often irrelevant. What IS relevant is
clearility of device design and number of variations for the "same"
hardware. Take look on aic7xxx driver: it's here for A LONG time, it's
maintainer CONSTANTLY tries to workaround bugs in different incarnations
of that beast and STILL it often lock ups and generally does not work
properly. How long crap is available is irrelevant: if card is crap driver
will be crap. With binary compatibility across kernel versions of without.
> 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".
And know what ? Very often problems can be solved by small changes in driver
and recompilation... That's what you can not do with binary drivers...
> 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.
You were unlucky :-) As we are used EXACTLY same configuration many times
sucessfully. The problem with NE2000 is that there are A LOT OF different
cards marked "NE2000-compatible". A lot of work great. Some lock ups
occasionly. Some did not work at all. Last time we used Novell Netware
with binary drivers (just year ago) the same was true for Novell Netware
as well.
> 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.
Relax. If it works for few days then it mean that it'll work just fine
for few years. Till you'll change kernel version at least. It's true for Linux,
Netware or Windows. And yes, 3c905B not listed as "Tier 1" exactly since
drivers are not solid enough. If you think that binary drivers will help
here you are wrong. It's not a case.
> 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.
I bet problem was triggered not by changes in driver but by deep rework of
network code. It's just like overclocked processors: 2.2.x fails MUCH faster
on them then 2.0.x kernel. It does not mean 2.2.x is buggier -- it's just
means you have buggy hardware. You had it even with 2.0.x -- it just was not
stressed enough.
> 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.
Unfortunatelly I know of NO WAY to ensure such compatibility. Novell Netware
has such problems, Windows NT has such problems, Sun OS is not exception, etc...
All of them are implemented "driver conformance tests", are using binary drivers
and so on. Still problem persists. MAY BE (I think that this problem will be
here forever, but who knows?) problem can be solved but binary drivers are NOT
way to solve this problem. It can make problem worse, not better.
> 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.
I'm yet to see hard numbers to prove that claim. Yes, I heard that "FreeBSD
is more stable" claim many times. I NEVER seen numbers behind such claims.
And EVEN if such numbers are exist it proves nothing: FreeBSD and Linux are
way to different to make claim that FreeBSD is more stable due to support
of binary portable kernel modules.
> 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.
To make binary portable drivers possible they need to do some serious work.
Since binary posrtable drivers does not help to solve ANY problems important
for them why to do this work ? This is the reason. What Linus said is the
following: since you can do open-source kernel driver for 3dfx when
specifications are open why we should try to do a lot of work and support
binary only drivers ? So you DO NOT need reasons to reject protable binary
drivers support. Not at all. It's the other way around: you need strong,
REALLY STRONG reason to support them.
Binary portable drivers are not implemented in Linux NOT since Linus and Alan
want to force someone to do something. They are not implemented since noone
proved that it will help to make things better. When something done with Linux
kernel it's done on purpose. And IF portable binary drivers will be supported
(in UDI form or any other form) it'll be done on purpose. What's the reason to
support them ? I see only one clear reason to make such drivers possible: to
help companies to keep specs in secret. And Linus responce for THAT benefit
sound quite reasonable:
> Why would I go to the extra work to help people who aren't even willing to
> help me?
-
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/