Messages in this thread | | | Date | Tue, 3 Feb 1998 15:39:46 -0800 | From | "Leonard N. Zubkoff" <> | Subject | Re: What is accepted into the standard kernel sources ? |
| |
From: Henrik Storner <storner@image.dk> Date: Tue, 3 Feb 1998 17:37:44 +0100 (MET)
[snip]
What I am trying to figure out is: What requirements are there for having new drivers added to the standard Linux kernel sources ?
The requirements are whatever Linus Torvalds is willing to accept, but I've previously had some discussions in this area and will give a summary here.
[snip]
Now, whether or not the Olicom driver is included with the standard kernel sources does not bother me a whole lot - if necessary, we will just let people download the patch from our web servers. However, looking at the 2.1.84 sources it seems that some drivers already in the standard kernel do include binary-like modules (usually, firmware of some sort) - most often, SCSI-drivers and drivers for multi-port serial cards. I suppose that these kind of hardware devices will not work without the binary firmware, just like the Olicom driver will not work without the binary library.
So is there a clear distinction between the kind of binary modules that are accepted in the kernel sources, and those that are not ? Personally, I cannot see the big, conceptual difference between a binary module that contains "firmware", and a binary module that contains the equivalent of firmware, but is executed by the host CPU rather than some embedded processor.
Linus and I discussed this at length regarding the Mylex/BusLogic FlashPoint SCSI Host Adapters. The FlashPoint SCCB Manager library code runs on the host CPU essentially in place of firmware running on an onboard processor as with the MultiMaster boards. Any software that runs on the host CPU is *required* to be in source form; binary is considered perfectly acceptable for firmware that is downloaded to a board, though obviously source for that would be nice too. One of the key conceptual differences here is that at least in theory, a driver in source form with downloaded binary firmware can execute on any hardware-compatible platform Linux runs on, or can be made to do so. The binary library module would have to be provided by your company for each Linux platform to be supported, and that does make a conceptual difference.
In a wider perspective, a hardware vendor who wants to support Linux currently has three options:
1) Release hardware specs and let someone write a driver. 2) Write a driver himself and release it in binary form only. 3) Provide an API for dealing with the hardware, and have someone develop a driver based on this API (the "Olicom" way).
Or:
4) Recognize that the library implementation does not really need to be kept secret, and provide it in source form. Mylex/BusLogic took this approach and the FlashPoint boards are now quite popular among Linux users. Despite dire predictions of a few people internally, the world has not collapsed due to their having done so.
(1) is how it has usually been done so far. (2) is unacceptable to many Linux users, as there is no control at all over what the driver does; from the hardware vendors point of view, it also removes the possibility of Linux users suggesting improvements and changes to the driver.
In my opinion, (3) is a workable compromise between the two (but obviously, I am biased). As I see it, both sides would benefit from such an arrangement - the Linux users would have more hardware to choose from when building a Linux system, and the hardware vendors would be able to offer their products for use on a very popular platform.
My personal approach to the similar situation with the FlashPoint was that for option (4), I would volunteer to write the driver primarily as a service to the Linux community, and the manufacturer just happens to benefit greatly as well. I consider option (3) to be inappropriate as a *volunteer* effort, especially since it can never be made part of the standard kernel sources. Mylex did consider option (3) for FlashPoint, and I would probably have written such a driver as a "work for hire" if necessary, but I would have considered any ongoing support and maintenance to be their ultimate responsibility. Option (3) is certainly preferable to option (2), since it does allow for some outside maintenance, but I still view it as your company's responsibility to be or hire the "someone" in that case.
That's just my personal perspective on the tradeoffs. Others might feel differently; I expect quite a lot from companies who are going to benefit from my volunteer Linux work.
I've always thought of the Linux community to be rather pragmatic - the "if it's useful and doesn't bother anything else, let us have it" approach. So I hope this can generate a useful debate, and is not shot down immediately with a "we want full source, or nothing" statement.
Indeed, there is quite a bit of pragmatism, and no doubt there will be people willing to use a binary only or hybrid source/binary driver if that's what you make available. But no such solution will ever be the preferred approach, nor will it ever be part of the standard kernel, unless Linus changes his views drastically in this area.
Leonard
| |