Noam Chomsky gave an incredible lecture at MIT about the war, as part of MIT's Technology And Culture Forum. To listen to it, you'll need realplayer. If anyone knows of an mp3 source, let me know. Here's a text transcript of the talk.
I recommend the talk very highly. For those of you unfamiliar with Chomsky, Google has a section on him.
Keith Owens had had enough, and decided to do something about it. He said:
That has been a lot of uninformed and confused comment on l-k about MODULE_LICENSE and EXPORT_SYMBOL_GPL. I will try to make this as simple as possible, to improve the signal to noise ration on this list.
Don't bother cc'ing me on any replies. Also I don't care what your view of the GPL is or should be.
MODULE_LICENSE
MODULE_LICENSE() allows kernel developers to identify kernels that have been tainted by modules whose source code is not generally available. No source code means that only the supplier can debug the problem so send the bug report to them, not l-k. Precisely which license string indicates that source is freely available is still being fine tuned.
A module without a license must be assumed to be proprietary. Not all existing modules have a MODULE_LICENSE() yet but most do, the rest are not far behind. For code that is not in the standard kernel tree, it is up to the supplier to set the license string accordingly. I recommend that binary only modules contain a string like :-
MODULE_LICENSE("Proprietary. Send bug reports to joe.bloggs@somewhere")
Modutils marks the kernel as tainted when it loads a module without a GPL compatible MODULE_LICENSE(), reporting the license string so users know where to send bug reports. Oops reports the tainted status of the kernel. Kernel developers can decide if they want to look at tainted bug reports or not. End of story.
Somebody raised the red herring of linking proprietary code into the kernel. If you compile and link code into the kernel and do not provide the source then you cannot distribute the resulting kernel. To do so is a breach of GPL conditions, read the GPL if you don't believe me. There is nothing to stop you building your own kernel with binary only code and using it internally, but any bugs are your problem and you cannot distribute the result.
EXPORT_SYMBOL_GPL
Some kernel developers are unhappy with providing external interfaces to their code, only to see those interfaces being used by binary only modules. They view it as their work being appropriated. Whether you agree with that view or not is completely irrelevant, the person who owns the copyright decides how their work can be used.
EXPORT_SYMBOL_GPL() allows for new interfaces to be marked as only available to modules with a GPL compatible license. This is independent of the kernel tainting, but obviously takes advantage of MODULE_LICENSE() strings.
EXPORT_SYMBOL_GPL() may only be used for new exported symbols, Linus has spoken. I believe the phrase involved killer penguins with chainsaws for anybody who changed existing exported interfaces.
System calls are not affected and cannot be, that is yet another red herring. Anybody who thinks otherwise does not understand the GPL. System calls define how user space code accesses the kernel, nobody pretends that a binary only user space program cannot use a syscall.
Alexander Viro added:
... and if somebody thinks that replacing
int foo(void *bar);
plus
EXPORT_SYMBOL(foo);with
int __foo(void *bar, int baz);
static int foo(void *bar)
{
return __foo(bar, 0);}
plus
EXPORT_SYMBOL_GPL(__foo);is going to save you from aforementioned killer penguins, keep in mind that there are worse and slower ways to go and you might not like learning them first-hand.
Elsewhere, Kai Henningsen speculated, Incidentally, an argument can be made that using EXPORT_SYMBOL_GPL
actually renders your code incompatible with the GPL, insofar as it
violates the "additional restriction" clause. Which doesn't matter as long
as it's *only* your code (author can always do different things), but *does*
matter if you add *other* people's GPL code (such as the rest of the kernel),
because it's *their* GPL that you're breaking ...
But Nils Philippsen
countered, Not the least -- there is no such
thing as code "(in)compatible with the GPL" -- you can alter (or write)
GPLed code to do (or don't do) anything you want when it comes to the GPL. The
additional restrictions provision in the GPL you talk about means restrictions
in licensing, not technical ones. For what it's worth I could alter the glibc
to not work when used by a process called "acroread" or "vmware" or whatever
(not that that would make sense) and still be in full compliance with the
GPL as long as I adhere to the GPL when distributing it.
Elsewhere, the point came up that existing modules might break under the
new system, and John Alvord replied, Linus said
that all existing entry points would remain untagged. Thus existing modules
would not be affected.
At one point David Lang claimed that the BSD (without the advertisement clause) was GPL compatible and should therefore not taint the kernel, but Keith replied:
The BSD no advert license is not considered GPL compatible in the kernel. Only Dual BSD/GPL is non-tainting, because the code is also available under the GPL. Anybody taking advantage of the BSD no adv license to create a binary only module will be tainted.
That causes a problem for some modules in the kernel tree that have the BSD no advert license. Ideally these should be changed to dual BSD/GPL but that may not be possible. Since their source code is always available, we might change them to
"BSD without advertisement clause, source is in the kernel tree"
and add that string to the non-tainting list. BSD no advert code that is not in the kernel tree can either switch to dual BSD/GPL or be tainted, at the choice of the supplier.
Alan Cox replied, BSD no advertising with no patent
issues (and therefore compliant) linked with GPL code ends up as GPL anyway,
so I don't see the problem in using the dual BSD/GPL tag
Robert Love announced:
Testers Wanted:
patches to enable a fully preemptible kernel are available at: http://tech9.net/rml/linux for kernels 2.4.10, 2.4.12, 2.4.12-ac3, and 2.4.13-pre5.
What is this:
A preemptible kernel. It lowers your latency.
What is New:
- sync with new kernel releases
- if HIGHMEM_DEBUG was on the preempt counter would be incremented at times but never decremented. this resulted in preemption becoming permanently disabled.
- if HIGHMEM_DEBUG was not on, HIGHMEM would crash the system horribly due to a case where preemption was enabled without a corresponding disable.
- reapply dropped hunk to pgalloc to prevent reentrancy onto per-CPU data
The next few patches are going to work on identifying any remaining per-CPU variables that need explicit locking under preemption.
Szonyi Calin saw a great improvement with the patch and asked if it would make it into the main tree, and Robert said it might in 2.5.
Colin Phipps reported a crash while running the patch. He posted the
oops, and reported, It occured when the machine
was under light load, I had just exited X, and I was logging off a console -
I may have hit ctrl-d twice.
Andrew Morton replied:
This one has been reported before.
n_tty_receive_buf() puts a character into the tty queue and then calls con_flush_chars(), which touches tty->driver_data.
Problem is, there's a window between these two operations where the device can be closed (especially if the char is "^D"!), and con_close() will zero out tty->driver_data. Hence null pointer deref.
I don't really believe this explanation, because the timing's wrong - the reader isn't woken until after the flush is called. Hence it'll be very difficult to actually trigger this race. It's probably something else. But a bit more sticking plaster should make it appear to be fixed.
He posted a patch; Robert added that he also had a patch, but that Andrew's was much simpler. He offered to send it to Colin if Andrew's didn't fix it. Someone else had a question about Andrew's version, but there was no discussion.
Michael T. Babcock asked how ugly it would be to make Rik van Riel's and
Andrea Arcangeli's Virtual Memory subsystem code into a compile-time option,
so folks could try each one out as they pleased. Alan Cox replied simply,
Too ugly for words.
Mike Fedyk suggested
that it might be feasible in 2.5, and asked if there were a way to make it
non-ugly. Marcelo Tosatti replied, Even if its
non-ugly, its non-easy. Way too much overhead. For 2.5 we'll probably be
able to get people working together.
At one point, Daniel Phillips suggested giving 'config' the ability to
apply patches. He said that would make it much easier to do what Michael
wanted. Ed Tomlinson replied, Actually this _is_ a
workable solution. IBM has done it for decades with its 'VM' operating system.
You get a base file, a couple of control files, and a lists of patches.
When you go to build a nucleus (translate kernel) the patches are applied
and the source assembled...
Keith Owens also added:
It is kbuild rather than config that needs the ability. I could do it trivially in kbuild 2.5, I almost added the facility at one time. Alas it breaks when you get overlapping patches, select one config or another and it works, select both (assuming they are not exclusive) and it breaks.
I don't have a solution and the symptoms of overlapping patches are worse than the problem that patches are trying to fix, so I left patch support out of kbuild 2.5. You can use shadow trees where you overlay a new implementation of a subsystem over the base kernel, then switch between versions by specifying which set of trees you are using.
Elsewhere, Alan said that by 2.5, he hoped there would be consensus on
the direction of the VM. Marcelo Roberto Jimenez said, maybe there was no
ultimate VM truth to be had, and Oliver Xymoron replied, In the event that we're unable to determine which one has the best
performance in a finite amount of time, the simpler design wins. So there
will be a decision.
Shawn Walker noticed that the most recent version of supermount was for kernel 2.4.0; he asked if anyone had ported it to a more recent kernel, and Jonas Berlin replied:
I mailed the same question to the maintainer over six months ago but didn't get any answer. So I upgraded the patch myself to work with versions 2.4.2, 2.4.4 and 2.4.5. At some point I switched to using 2.4.4-ac9, which I am still using without problems, but I didn't have time back then to port the patch to that version.
I have no idea if anyone else has done anything similar. Personally I initially found this patch as a part of the standard kernel provided by mandrake 7.2 (most likely), but I don't know whether they have it in there anymore. I'll check that out. Anyway, if nobody else is already doing it, I could try my best to port it to the newer kernels available, and also to the -ac series, and if I succeed, possibly continue porting it when new versions arrive. I'd be happy to have supermount support back in there myself too.
As this is the first part of kernel software I have been porting anyway, I'll happily listen to good advice and pointers to resources that could help me figuring out what interface changes etc there has been in the 2.4 series. I remember there being multiple changes already between 2.4.0 and 2.4.4 that required changing some code, partially because the patch also includes some small changes to some generic fs code (mostly locking issues).
Marcelo Tosatti replied, saying, Last
I heard, Juan J. Quintela <quintela@fi.udc.es> was porting
supermount to 2.4.x. From what I heard from him its not an easy job:
the current 2.4.x available patches are full of problems.
And
Christian Borntrager pointed out that Mandrake had supermount working
under 2.4.8 in Mandrake 8.1; and Alan Cox also added, Alternatively you can do the same kind of stuff in userspace
now thanks to Al Viro's mount cleanups. Take a look at volumagic on ftp://ftp.linux.org.uk/pub/linux/alan/.
its strictly a proof of concept