Not really. The binary format is dependant on compiler, architecture, SMPness
and a dozen other things. The source is not. Binary compatibility killed windows
Windows 98 could have been a much nicer OS without back compatibility. I see
no reason to kill Linux by re-enacting proprietary OS history with a free
OS.
You can (and people do) swap drivers between kernels. What we need to get
better if anything are the tools for building modules for users transparently.
So I can for example do
rpm --install emu10k.i386.rpm
and have it build my a SBLive! module for my system and do the dependancies.
Ditto for dpkg.
> 2. Binary portability requires more solid and clearly defined
> interfaces between the kernel internals and the modules themselves.
You mean slower, multiple and in frequent cases legacy overhead. You want
every Linux user to have a slower more buggy system so a few people can use
your product, how considerate you are.
> EtherExpress XL PCI boards). In particular note the lack of *any*
> NE2000 compatible adapters in this list.
No NE2K vendor ever submitted some for evaluation and testing to my knowledge.
If you look at tier1 you'll generally see products that vendors are shipping
now and care about. NE2000 clones are something vendors shipped and have no
desire to do any more with other than their customer obligations. It doesnt
help their bottom line.
> 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.
You do yourself no favours. You have a personal agenda to ship proprietary
Linux modules. As Linus and I both told you, feel free - but _YOU_ and not
the community can support the results. Its a simple matter of maintainability
and debugging.
Anyone using your modules is your problem. People with kernel bug reports of
any kind with your modules loaded will be referred to you, and binary
compatibility messes will be yours to deal with. You have our source, we dont
have yours, so you can debug it we cant.
Its your overhead, created by your product and desires. In the proprietary
world every vendor pays their own support costs, I don't see why it should
be different here.
Alan
-
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/