Messages in this thread | | | From | "Kendall Bennett" <> | Date | Sun, 5 Dec 1999 14:30:15 -0800 | Subject | Re: 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.
Exactly.
> Then "all" that has to be done is to maintain the (open source) > translation layer, the binary drivers always see a consistant > interface.
Yes.
> 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 drivers.
> 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.
Regards,
+---------------------------------------------------------------+ | 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 majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |