Roy Schestowitz wrote:
> Penguin haiku (or "why the Linux Kernel Embraces the GPL")
>
> ,----[ Quote ]
> | It's always an interesting day when you get to write a kernel patch,
> | at the urging of Andrew Morton, that notifies the world that non-GPL
> | Linux kernel modules will not work after January 2008 and write some
> | poetry all in the same message.
> `----
> http://www.kroah.com/log/2006/12/13/#2006_12_13
The current practice is to write a "probe" in GPL and write a shared
library in LGPL, which then calls the proprietary code as a shared
library. This is very similar to a "plug-in" in that the driver does
not have to be compiled into the kernel (previously a big problem for
UNIX systems), and at the same time, the GPL code doesn't get infected
by proprietary code - and vice versa.
For a variety of reasons, mostly involving lawyers and bean counters,
many device drivers cannot be published in source code format. Using
an NDIS driver, for example lets Linux users use standard drivers
written for MS-DOS or Windows, without having to know the proprietary
internals. The NDIS specification itself is a public specification,
and the drivers can usually be loaded in a position independent way,
which means that Linux gets a lot more peripherals without having to
try to convince Microsoft partner IHVs who fear retaliation from
Microsoft, to publicly endorse a Linux driver.
Most drivers aren't rocket science. You fill a buffer, output to a
port that tells where the buffer is, and get an interrupt that
acknowledges that the buffer has been processed. The send and receive
can be separate transactions, but the principles aren't significantly
different whether you are writing to an IDE port, a SCSI drive, an
Ethernet port, a USB port, or a WiFi device.
Graphics display and print devices are more interesting because there
are protocols that handle more complexity. For example, printers might
speak PCL or PostScript. Display cards might speak X-wire, OpenGL, or
DirectX, each of which involves buffering a sequence of commands which
are sent to the card, which interprets and impliments those commands.
The irony is that these "binary only" drivers often handle some of the
DRM issues. For example, publishing source code to DVD-CSS might be a
crime in the united states, but a binary DVD-CSS module from a vendor
who has paid the 25 cents/PC to license, has a pretty good chance of
decoding those DVD movies without the author going to jail.
One of the nice things about Linux distributions is that there is lots
of competition within the established framework. As a result,
distributors are very pragmatic. Debian can be true to their ideals of
"GPL and LPGL only" and yet other distributions such as Knoppix and
Ubuntu can provide the hooks for the stuff that most people want, and
won't do without.
> Discussion here:
>
> http://thread.gmane.org/gmane.linux.kernel/475654/focus=475824
|
|
