Messages in this thread | | | Date | Mon, 6 Dec 1999 00:08:03 +0000 | From | Thorsten Kranzkowski <> | Subject | Re: 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
How?
> 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
-- | Thorsten Kranzkowski Snail: Niemannsweg 30, 49201 Dissen, Germany | | Mobile: ++49 161 7210230 Inet: dl8bcu@gmx.net | | Ampr: dl8bcu@db0nei.#nrw.deu.eu, dl8bcu@marvin.dl8bcu.ampr.org [44.130.8.19] |
- 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/
| |