Messages in this thread |  | | Date | Sun, 16 Jun 1996 14:21:36 -0700 | From | "Leonard N. Zubkoff" <> | Subject | Binary Driver Issues |
| |
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 it is now impossible for the Linux community to stop manufacturers from issuing binary only drivers, I think it is worthwhile to encourage compromises that meet the needs of both the Linux community and the manufacturer's desire to protect their intellectual property. Manufacturers are not in the business of supporting Linux out of the goodness of their corporate hearts. If they perceive that support for Linux requires revealing valuable proprietary information to their competitors, they will weigh the risks versus the benefits, and may well decide that the risks cannot be justified.
In this message, I would like to explore some possible scenarios and stimulate public discussion on this topic. As many people are probably aware, I have been working with BusLogic over the past year, and in most ways they have been extremely supportive of Linux and my efforts. I believe my experience dealing with them may help shed further light on some of these issues. I work directly with their engineering staff and have been a beta test site for their most recent products and firmware updates, assuring that they work well with Linux. When non-technical problems have arisen, such as the question of FlashPoint support last fall/winter, senior management has been willing to meet with me and discuss possible solutions, which led to the FlashPoint upgrade program for Linux users. So, with this level of support and interaction, why then are the FlashPoint series host adapters not supported on Linux?
With the MultiMaster series host adapters, the boards have an onboard CPU that controls the SCSI and host interfaces, and there is a reasonably high level interface for interacting with the board. The defined interface to the MultiMaster host adapters still deals in shared data structures and I/O ports, but the responsibility for controlling the internal registers in the SCSI controller and bus mastering chips resides with the firmware running on the onboard CPU, not with the OS driver. If the board manufacturer is responsive and corrects any firmware problems rapidly, this scenario is ideal for both the manufacturer and the Linux community. The manufacturer accepts the responsibility for making their chips interact correctly with the SCSI bus and host CPU according to the defined interface. The driver author then provides the interface glue between the Linux SCSI subsystem and the defined host adapter interface. The firmware is shared among all operating systems that support the host adapter, and all SCSI devices the host adapter is used with, so whenever a particular firmware level problem is discovered and fixed for any operating system or SCSI device, that fix is shared by everyone.
This scenario also neatly solves the problem of protecting a manufacturer's intellectual property. Their proprietary information is all embedded in the firmware, and the source code for the firmware is not likely to be released, except perhaps in very limited circumstances under an appropriate non-disclosure agreement. While we could expect or demand firmware source code or even board level schematics to be made available, I don't believe this has ever been suggested, and the Linux community seems comfortable with this boundary between the publicly available and proprietary information.
The problem that now arises with more recent controllers is that what is conceptually the board's firmware is now migrating to become part of the device driver itself. The logical distinction between the firmware and the driver software is still there, but the packaging has changed in a way that makes support by free software difficult or uncomfortable. Host system CPUs are continually becoming ever more powerful, and so a controller design that incurs some overhead on the host CPU can be very cost effective, so long as the SCSI controller chip is designed well to minimize this overhead. The FlashPoint series boards are a case in point, as are the Adaptec aic7xxx chips and the Symbios/NCR 53c8xx series. The FlashPoint series boards are in many ways comparable to the Adaptec 2940 series, but they are priced more similarly to the 2920 which provides a much lower performance PIO interface.
Within BusLogic itself, and with any outside driver support where release of driver source code is not an issue, the defined and documented interface to the FlashPoint boards is not presented at the chip level. The supported interface assumes a low level library that is conceptually the firmware for these boards, and whether we like it or not, the source to that library is not likely to be released publicly, because it is believed to reveal too much of the company's proprietary information and competitive advantage. Even if we suppose hypothetically that BusLogic would permit me or someone else to write a driver that interfaces directly with the SCSI controller chip, I would not willingly undertake such a task. They have well over a person-year of effort in their library, and I have no reason to believe that I or any other member of the Linux community could produce a robust driver at the chip level with substantially less effort. It's craziness to duplicate their effort rather than finding a way to take advantage of it. Just look how long it has taken to achieve reasonably stable drivers for the Adaptec aic7xxx and Symbios/NCR 53c8xx chips, and my impression is that programming them is easier.
Consider the following implementation strategies manufacturers might use, and which of them are easier or harder for free software support:
(1) Onboard firmware and CPU with a defined interface like the present MultiMaster boards have: no problem at all, even though the chip level programming information is considered proprietary and is not revealed.
(2) Onboard firmware RAM and CPU where the firmware is downloaded by the device driver: no problem so far. Both the AdvanSys and DGRS drivers seem to include downloadable code for which no intelligible source is provided. In both cases, there is compilable source code but it comprises a constant array of binary data. I've not read of any complaints with this approach, even though one could argue that full source is not being provided.
(3) Onboard Firmware that implements an interface library as ROM entry points on the board: in this case the firmware is executed by the host CPU rather than a CPU on the board, but if the defined interface is through these routines, a driver can still provide full source code without revealing chip level programming information.
(4) An interface library that runs on the host CPU implemented as a virtual ROM where the binary data is a constant in the driver rather than being on the board. There's very little conceptual difference between this and (3), but it makes for lower cost hardware and easier library updates.
(5) An interface library implemented as object module data which can be insmod'ed directly by the driver code. The library is still binary data, but now that data requires some minor linking to be used. Depending on how you wish to interpret the technicalities, the driver is still compilable from source and linkable with the kernel.
(6) An interface library implemented as an object module that is linked with the kernel and a device driver in the normal way.
(7) A full Linux device driver but provided only in binary form. An initial bootable kernel using initrd can be provided, and then end users can link a regular kernel if they so choose, but they clearly cannot redistribute it without violating the GPL.
(8) A full Linux device driver provided in source code form.
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.
Leonard
|  |