Messages in this thread |  | | From | Albert Cahalan <> | Subject | Re: Binary Driver Issues | Date | Mon, 17 Jun 1996 02:24:22 -0400 (EDT) |
| |
From: "Leonard N. Zubkoff" <lnz@dandelion.com> > > 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.
|  |