[lkml]   [1999]   [Dec]   [5]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Binary drivers
Hi Peter,

> This solution has been suggested before.

Yes, and I have proposed similar solutions many times before.

> Adopt one kernel API as stable, provide an Open Sourced component
> that translates the kernel API's between that API and the current
> working kernel.


> Then "all" that has to be done is to maintain the (open source)
> translation layer, the binary drivers always see a consistant
> interface.


> 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. 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.

And the kernel API's don't get frozen because of this. If you change
the kernel API's, you just need to extend the exported device driver
API to include the new kernel level API's so that newer drivers can
take advantage of this for maximum performance.

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. 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.

> Basically, both approaches are the same, except for the fact that
> one disadvantages those who want to ship binary-only drivers that
> are stable across OS versions, the other disadvantages the whole
> kernel.

Garbage. It takes finite amounts of time to re-implement existing
device drivers using a new kernel level API. No-one in the right mind
is going to arbitrarily change this at will. Doing so will then break
compatibility with all the existing device drivers that have been
developed, requiring all the device drivers to be re-worked to
support the new interface. As soon as you do that, you have to retest
*evert* single device again to ensure it is working properly and you
have not introduced new bugs.

Hence before Alan or Linus or anyone else seriously considers
changing critical kernel level API's, consideration must be paid to
ensure compatibility with the existing sources. Doing so could push
back the release of a new Linux kernel revision by months to iron out
the potential bugs that introduced into all the existing device

> 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.


| SciTech Software - Building Truly Plug'n'Play Software! |
| Kendall Bennett | Email: |
| Director of Engineering | Phone: (530) 894 8400 |
| SciTech Software, Inc. | Fax : (530) 894 9069 |
| 505 Wall Street | ftp : |
| Chico, CA 95928, USA | www : |

To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:55    [W:0.142 / U:2.180 seconds]
©2003-2018 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site