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