lkml.org 
[lkml]   [1999]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    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

    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/

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.039 / U:0.672 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site