Messages in this thread | | | Date | Mon, 6 Dec 1999 19:31:32 +0100 (CET) | From | Ingo Molnar <> | Subject | Re: Portable binary drivers |
| |
On Sun, 5 Dec 1999, Kendall Bennett wrote:
> Binary portable modules != close source proprietry drivers
> I would rather see vendors release Open Source device drivers because > they understand these benefits, than because they are forced to do > so. Then Linux and the Open Source revolution will win because it is > just plain technically superior.
why should Linux make it easier for anyone to hinder Linux development? Closed-source drivers are definitely bad - not only for the hardware vendor (it's their problem and they are free to create whatever additional headache for themselves at will), but more for Linux users. Even if we had an ideal driver API, which stayed constant over time. [which is impossible btw. as it contradicts some of the fundamental properties of Linux] And Linux is _not_ neutral towards constructs that hinder Linux development and hurt Linux users. Linux _is_ neutral towards other binary-only constructs, like user-space applications. But kernel space is much more different.
Linux could flatly refuse binary modules, do you see that? Binary modules are allowed nevertheless (take this as a gift!), but we simply cannot guarantee cross-kernel-branch compatibility without hindering Linux development. Nevertheless as you might have noticed, we try to keep the driver API constant within the 'stable kernel branch'. Sometimes we have to break module compatibility, but we try to avoid it _in the stable, production branch_ as much as possible. What is your problem with this?
why is it impossible to keep the module API constant? Because Linux evolves so fast, and the goal of Linux is to integrate drivers into the OS as much as possible. This is a constantly fluctuating process, APIs, constants and frameworks change frequently (and without us knowing about it advance). This is essential to Linux, it gives us speed and generic drivers. i386 networking drivers worked almost out of box on other architectures - this would be impossible with binary-only drivers. Because we simply cannot guarantee '100% binary compatibility', we do not guarantee it at all. It's not a clean concept.
sadly it's not possible to distinct between 'good' binary modules (which are open-source), and 'bad' binary modules (which are closed-source) - but this is not a problem! i'm sure you will understand the point: it's not hard to create a 'module compilation package' that compiles the binary module on the spot. We _do_ guarantee driver source-compatibility for the stable branch. An on-the-spot driver compilation framework would be a welcome addition to Linux (feel free to contribute it), as it can eg. optimize for the given CPU and architecture.
-- mingo
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu Please read the FAQ at http://www.tux.org/lkml/
| |