> Can someone of the Linux kernel gurus please explain me (and try to keep
> it simple, okay?) why exactly the Linux kernel can't have a consistent
> binary interface?
It *can*. It just doesn't.
(Actually, it does. The application binary interface for user-mode
programs has been frozen for a long time, and the standard shared
libraries have a binary interface that changes very seldomly, but
that's not what you're interested in, of course.)
Quote:> Isn't it time to give the kernel such an interface as well, so companies
> can write drivers for the Linux kernel and distribute them in binary
Binary-only modules generally cause nothing but heartache for kernel
developers. It's hardly surprising that they don't want to spend much
time and effort freezing a binary interface and then living with the
resulting inflexibility and potential inefficiency (when underlying
structures have to change and someone has to add a conversion layer)
when the tiny group that'll benefit only causes them grief.
Quote:> But at least within a "kernel family" so to say, the interface would
> stay the same, so a company could offer binary kernel modules on
> their webpage, saying "This one is for 2.2.x, this one is for 2.4.x,
> this one is for 2.6.x and so on".
Oh, within stable branches, the interfaces usually *are* frozen. (Not
officially, but by convention.) Besides which, once a stable branch
has actually stabilized, new minor versions are released so
infrequently that a vendor should have no trouble offering a module
for every possible stock kernel version.
Quote:> That would help the people creating distributions a lot and it would
> help users a lot as well, as they can always re-use their compiled
How would it help?
Distributions usually bundle kernels with the standard set of modules
compiled for that kernel. If they're bundling proprietary kernel
modules, too, they already have a licensing agreement with the vendor,
so they can and should demand modules compiled for the kernels they're
planning to ship. How does having a frozen binary interface help
For those users that want to upgrade their kernel by hand, why would
they upgrade their base kernel and not the modules? Given that the
kernel *is* highly modular, bug fixes and improvements are going to
appear all over the place, in modular and non-modular parts of the
kernel. What benefit could there be to upgrading your "bzImage" and
not your modules? How would you even *start* to file a bug report on
Dear Alan Cox,
I am running a bzImage from linux-2.5.22-ac16-pre3, network
modules from linux-2.4.18 (except for my IPV6 support from
linux-2.5.22 stock), filesystem modules from linux-2.4.19-rc1,
and blah blah blah). It crashed. Please help me.
Quote:> thus it would also help companies that don't write drivers for Linux
> out of a simple reason only: They don't want to distribute them as
> source code.
Wah. There are several approaches. First, and most obviously, you
can make a sound business decision and commit to supporting a
collection of kernels that will make your customers happy. Often,
this means tracking a popular distribution: whatever Red Hat's kernel
du jour is, commit to having a module ready for it, for example.
Second, for your kernel junkie customers, you can take the trouble to
put a little thought into your design. You can usually do all your
3l33t, sekrit processing in user space supported by a simple, freely
distributable stub kernel module, and this is a better approach for
most applications anyway. Alternatively, you can deliver a tarfile of
object code and a stub C interface with a Makefile---instant
compatible kernel module!
Let me emphasize that this is a two-prong approach: for users that
*don't* compile their own kernels (and may not even know what a
tarfile is), you track a distribution's kernel updates. To make users
that *do* compile their own kernels happy, you provide them with
advanced tools, which they are perfectly capable of using, to compile
their own versions of your module.
Quote:> Or is this some ideology nonsense?
Oh, you're one of those, are you?
Quote:> "Either your driver is open source or keep it away of the kernel"?
Nope, either your driver is open source, or you get off your *y
ass and stop expecting kernel developers to do your support work for
you. If you can charge for your module, you can make a sound business
decision about which kernels you're planning to support and which
customers you're willing to turn away.
Quote:> Why must every hardware support be open source, just because the
> Kernel itself is? How's that an advantage if it means that hardware
> doesn't work at all, doesn't work properly or is so limited in
> functionality that it was a waste of money to buy it?
My hardware works great, and it's all supported by open source
drivers. You don't have to make careful purchasing decisions if you
don't want to, but don't start whining when your lack of due diligence
makes life difficult for you.