> > And, yes, there will be obvious performance hits in some cases,
> > but thats exactly WHY Linus and Alan don't support binary drivers
> > now. If they do that, the kernel API's get frozen and they lose the
> > ability to innovate.
>
> Wrong. You will only get a performance hit *if* there has been a
> change to the internal kernel API's that necessitate a compatibility
> layer to be implemented so the old drivers can still be used.
And you'll carry that performance hit every time you make these changes.
How much of this should we carry? Should Linux 3.4 still support the old
PCI interfaces? If it did, it would be only to avoid losing some binary
driver whose author/supplier was undoubtedly negligent.
> This doesn't mean that a performance hit is necessary for all drivers.
> When a new kernel is released where the API's have changed, the
> drivers should be changed to eliminate the performance overheads by
> updating them to use the newer, faster interfaces.
You forget that:
* the Linux developers already do this, and they do it well
* not all API changes are introduced for performance reasons
> This is what developed OS'es in the real world is all about. Every
> commercial OS on the planet does things this way because that is the
> only way to guarantee reliability down the track.
*Linux is a real-world OS*
> Alan can complain about the stability of Windows 9x being attributed
> to binary drivers, but the same argument does not hold true for
> Windows NT, OS/2, Solaris, Netware, QNX, BeOS, MacOS or any other
> commercial OS. Fact is they all use binary device drivers, and many
> of them are a lot more stable than Linux is.
Allowing for binary-only drivers is both a design decision and also a
necessity for those OSes. With the exception of NT, Linux has a much
richer set of drivers available, too.
Stability is not the issue, though. Show us some lmbench numbers for
Solaris/x86, or equivalent microbenchmarks for the others. Linux does
better because it doesn't have to allow for every silly eventuality
when it can adapt to real requirements as they actually happen.
> > I know which I'd prefer.
>
> Put it this way. I would rather have the latest wiz bang internal
> kernel interface get developed with a compatibility layer so existing
> drivers can actually work (with a performance hit), rather than having
> to wait for months before I can use it at all because the kernel
> drivers for my devices have not yet been updated to support the new
> interfaces. Or worse that someone considering themselves to be
> superman hacks the existing drivers so they will compile with the new
> interfaces without actually being able to test all the drivers.
I'm afraid I don't believe that you can come up with a worthwhile example
of this ever having even nearly happened.
The Linux device driver interfaces (such as they are) are fairly stable
indeed. The higher-level interfaces (for filesystems, for example) are
a lot more mobile, but this isn't your issue.
The fact is that stable kernels have a fairly static driver interface,
which is _almost always_ source-compatible, if not binary-compatible.
So there really is no disadvantage to driver writers who are willing to
contribute source, as far as I can see.
Matthew.
-
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/