[lkml]   [1999]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Linux headed for disaster?
On Sun, Dec 05, 1999 at 12:53:18PM -0800, Kendall Bennett wrote:
> 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.

<angry mode>
Grr - not again....
</angry mode>

> Every single problem that has been mentioned as reasons not to
> implment Binary Portable modules for the Linux kernel is solvable. In


> 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).

A later version of a kernel may well have discovered new bugs in a previously
considered stable driver. Solving this problem will require the user to
revert back to an older kernel revision.

> 2. Binary portability requires more solid and clearly defined
> interfaces between the kernel internals and the modules themselves.
> 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.

Clear api's are good. But consider an api that involves a 'uid_t' for
example. Just now there are attempts to bump this from 16 bit to 32 bit.
A well written driver using that api will work just well after such a
modification and a compile, perhaps no driver changes required. Your binary
module will horribly fail or introduce security flaws!

> 3. Binary portability means much less regression testing is required
> 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 do you *really* know that a binary driver is functioning.... ?

> 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 ---
[Red Hat support]
> ---- 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.

How do you expect your binary drivers to be better supported? Esp. when the
vendor just introduced that super-hyper-better-new model that you shall buy???

As a side note, I avoid ne2000 where I can because I've already been bitten
by some bad clones.
Oh - and I already dumped a $800 Multi-purpose framegrabber card because the
supplied win3.1/win95 driver never left beta status, a NT driver or specs
don't exist and support was abandoned a year or sth. ago. (the vendor is
"FAST Multimedia" btw.)

> 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".

Following this statement your binary modules won't get any higher
classification, because there are already strong technical reasons why they
*will fail* in the future (or the past).

[ne2000 nightmare snipped]

> 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 ---
[Linus mail]
> ---- 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.

Who *forced* vendors to support Linux at all?? Who *forces* you to use linux?

Do vendors force *you* to use Windows (because not giving you support/drivers)
for other os's)??
Remember: *Nobody* prevents them selling you binary drivers _yust now_!

> 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.

Aren't you getting unfair? After all Linux is GPLed - so go ahead and implement
your binary interface ("show us the code") - I'm shure there will be details
that break it in a couple of weeks if not days.

You would have to provide modules dependent on
- compiler (2)
there are known incompatibilities between gcc 2.7.x and newer ones
- architecture (5 - I didn't count...)
the world is not intel-only (my personally most important issue)
- processor (about 2 per architecture, more to come....)
even inside an architecture these are incompatible, at least from
a performance pov. (Think of MMX, SIMD etc etc )
- SMP (2)
lots of things default to /*nothing*/ or are handled differently
on UP - you dont want that SMP overhead on UP.
And thinking of your SMP-Compatibility functions you mentioned
elsewhere: You did realize that the head developers argue a lot
whether they can use *one* or must use *two* asm-instructions
to perform a specific task, just to save a few picosecs, didn't you?
Compare that with a multi instruction parameter passing and
probably cache trashing function call.
I would think Andrea says NO WAY! :)
- memory configuration (2-3)
You don't want the additional overhead of supporting a multi-Gigabyte
(RAM that is...) machine on your 486 8MB home toy machine, no?
- API-version (?)
I think even you agree the API has to be changed from time to time
to support newer/bestter features.

Even more points to add.

That's conservatively counted 80 (!!!) driver modules for a single API - do
you really think that will get supported???

Does any of your win95 drivers work for 98, NT3.5, NT4, 2000, or 3.1 ?
Imagine: a source driver could even be backported to 2.0 or something
should you need that somehow - a binary one never will.
And note ther _is_ a way to use binary drivers _just now_: it's called modules
and if I understood that correctly they even _have_ a module version which
makes them refuse to load when it is known that they break. So you _can_ use
them across kernel versions. But all other points remain....

> Regards,

I actually wonder whether you ever have programmed something yourself that you
still seem to constantly ignore the technical facts presented to you.

Usually I don't participate in flame-wars - but this posting made me angry :-/


| Thorsten Kranzkowski Snail: Niemannsweg 30, 49201 Dissen, Germany |
| Mobile: ++49 161 7210230 Inet: |
| Ampr:, [] |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.198 / U:1.360 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site