[lkml]   [1996]   [Jun]   [17]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: Binary Driver Issues
From: "Leonard N. Zubkoff" <>
> With Linux 2.0, the possibility of binary only Linux drivers provided by
> board manufacturers is only going to become worse. With previous kernel
> versions, the module facility allowed for dynamically loading binary only
> device drivers, but this mechanism could not be used for boot devices.
> With the very recent advent of the initial ramdisk facility (initrd) in
> Linux 2.0 and LILO 19, it is now possible to boot from a device by loading
> its driver from the initial ramdisk, without having to link it into the
> kernel. For better or worse, this opens the door to binary only drivers
> for boot devices.

> While I'd like to have full and complete source code for absolutely
> everything on my system including all controller firmware and even the
> motherboard BIOS, I realize that this is not a realistic goal, and that in
> reality many Linux users could care less and just want their hardware to be
> supported and to work properly. Given the above scenarios, which should be
> permitted, and which should be actively encouraged or discouraged by the
> community? I'd rather avoid true binary only drivers because they provide
> no way for Linux users to track changing kernel driver interfaces as
> improvements are made; users of such drivers will be forced to remain with
> the last kernel supported by the board manufacturer, and manufacturers are
> unlikely to allocate resources to updating their drivers as development
> kernels are released. But this level of support is what we may be faced
> with, or no support at all, unless we encourage acceptable compromises.
> I really believe we need to address this issue if we want Linux to achieve
> the mainstream success it deserves. I'd like to encourage discussion about
> which of the scenarios I've presented are acceptable, and what those of us
> who interact with manufacturers should request of them.

Implement a driver in each class (scsi, network, filesystem...)
that fits between the kernel and a binary-only driver. When the
kernel interface changes, the middle driver converts between the
new and old interfaces. This means that binary-only drivers do
not benefit from improved kernel interface design, but at least
they still run. Start with a null translation layer for 2.0.x,
then add whatever is needed to let 2.0.x drivers run with Linux
version 2.1.x, 2.2.x, and even 9.4.x.

Yes, this is gross. It works though, and it lets the driver
interface change. The translation layer can even have an
emulator so that the Alpha and PowerMac can use 386 drivers.
It can provide bug-for-bug compatibility so that drivers will
still work if standard kernel functions add better error checking
that crashes the old driver.

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