> > implment Binary Portable modules for the Linux kernel is solvable. 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:
> Not really. The binary format is dependant on compiler,
> architecture, SMPness and a dozen other things. The source is not.
As I said above, all these problems are solveable. You can solve
these problems easily by making sure your interfaces handle things
correctly. There are ways to normalise differences between compilers,
and compatibility tests are what you should use to check this.
Take XFree86 4.0 for instance. They support binary loadable modules
and they don't have these problems.
> Binary compatibility killed windows. Windows 98 could have been a
> much nicer OS without back compatibility.
Sorry, I completely disagree here. Backwards compatibility in Windows
9x was a choice that Microsoft made to sell the OS (and it worked;
OS/2 would have killed NT otherwise).
The binary driver model has *absolutely* nothing to do with the
stability of the Windows platform, and given the amount of respect I
have for you, I feel you should understand this quite well. The
Windows 9x platform is unstable because the foundation it was built
on (the 16-bit Windows 3.1 kernel) was not well designed to begin
with. Win32 services were wrapped around an inherently archaic, 16-
bit kernel. Windows NT is a totally different story, and a hell of a
lot more stable than Windows 9x.
Windows NT supports binary drivers, but you didn't say that binary
drivers killed Windows NT? OS/2 has binary drivers, and OS/2 is
probably one of the most stable OS'es around (Warp Server for e-
Business is incredibly stable). One reason why OS/2 is so much more
stable than Windows NT is because IBM takes binary compatibility and
conformance/regression testing *very* seriously (I know, because we
license our technology to IBM).
> I see no reason to kill Linux by re-enacting proprietary OS history
> with a free OS.
It got nothing to do with this. It is all about what mechanisms can
be put in place to allow for better compatibility with the vast
number of devices that Linux supports. A *real* operating system is
just not going to be able to survive unless some procedures and
policies are put in place to ensure future compatibility with legacy
> 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.
You miss one very important point which you did bring up briefly as
as something against binary portable drivers. Pure source drivers are
adversely affected by compiler compatibilty concerns, and unless the
user is bulding the updated sources with the *exact* same compiler
revision and kernel source code, you don't really have any idea
whether it will work. It should work, but how many times have you
seen compatibility problems where something should work (and did work
before) but a minor change, compiler bug or something else stopped it
from working in a future revision?
This is one reason why when IBM does builds of OS/2, if there are
updates to legacy components those components get built with the
compiler version the component was originally built with. If the
component was written 5 years ago with MSC 6.0c, it is re-built with
MSC 6.0c for the latest Warp Server for e-Business platform. Why?
Because that is one way to ensure repetable results.
> > 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.
Sure I would like to see binary portable drivers in the Linux kernel
so we can better support our products (of which some don't fit at all
well with Open Source). But that is not what this is about. If I need
to solve this problem, we will create our own Linux distribution
(they only way we can actually ensure compatibility anyway). We
probably will end up doing that anyway.
I am more interested in the future stability of Linux. I want to see
Linux succeed, but it needs better support for compatibility and
regression testing IMHO.
> > 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
What has this got to do with vendors? NE2000 compatible boards are
the most common boards around. Sure vendors don't want to support
them anymore, because they would always rather sell you a new network
card. That is how they make money.
But Linux *should* fully support those boards. Surely there are lots
of people who have those boards, and proper testing and certification
can be done regardless of whether a vendor submits NE2000 compatibile
hardware or not.
Imagine how bad the compatibile of XFree86 would be if no-one
bothered to ensure that the latest servers work properly on the old
S3 Vision chipsets? You can be sure no-one at S3 wants to help
support those boards, because they would much rather upgrade you to a
Savage2000. But developers on the XFree86 list have those boards, and
do reguarly test them to ensure backwards compatibility.
> > 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.
You do yourself no favours when you try to force people who want to
help Linux grow, to be forced into a model that is fraught with
compatibity issues. This is the whole crux of the matter. You are
totally against the concept of building support for binary portable
modules, because it might enable companies to develop proprietry
drivers for Linux? What about the fact that there are a ton of
positive benefit for compatibility issues in doing this? Are you
willing to jeapordise the future of Linux, just to stop my company
from being able to build binary portable modules? I didn't realise
that what I do has such a tremendous impact on the Linux community...
Why not look at the substance of my post, and respond to some of the
technical issues for why binary portable modules can help to make
Linux a much more compatible product? All you have done in your
response is try to downplay my reasoning by saying that I have some
hidden agenda to get binary portable modules into Linux so I can sell
| SciTech Software - Building Truly Plug'n'Play Software! |
| Kendall Bennett | Email: KendallB@scitechsoft.com |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : ftp.scitechsoft.com |
| Chico, CA 95928, USA | www : http://www.scitechsoft.com |
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to email@example.com
Please read the FAQ at http://www.tux.org/lkml/