Kernel Traffic
Latest | Archives | People | Topics
Wine
Latest | Archives | People | Topics
GNUe
Latest | Archives | People | Topics
Czech
Home | News | RSS Feeds | Mailing Lists | Authors Info | Mirrors | Stalled Traffic
 

Kernel Traffic #139 For 29 Oct 2001

By Zack Brown

Table Of Contents

Introduction

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.

Mailing List Stats For This Week

We looked at 973 posts in 4323K.

There were 408 different contributors. 166 posted more than once. 178 posted last week too.

The top posters of the week were:

1. More Discussion Of License Tainting

17 Oct 2001 - 21 Oct 2001 (25 posts) Archive Link: "MODULE_LICENSE and EXPORT_SYMBOL_GPL"

Topics: BSD, Patents

People: Keith OwensAlexander ViroKai HenningsenNils PhilippsenJohn AlvordAlan CoxDavid Lang

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"

2. New Preemptible Kernel Patch

19 Oct 2001 - 23 Oct 2001 (19 posts) Archive Link: "[PATCH] updated preempt-kernel"

Topics: Big Memory Support, Real-Time

People: Robert LoveColin PhippsAndrew Morton

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:

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.

3. More Discussion Of The VM Subsystem

22 Oct 2001 - 24 Oct 2001 (25 posts) Archive Link: "Re: VM"

Topics: Kernel Build System, Virtual Memory

People: Alan CoxMarcelo TosattiEd TomlinsonKeith OwensOliver XymoronAndrea ArcangeliMichael T. BabcockMike FedykDaniel PhillipsRik van Riel

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.

http://sourceforge.net/projects/kbuild

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."

4. Status Of supermount

24 Oct 2001 (6 posts) Archive Link: "status of supermount?"

People: Jonas BerlinMarcelo TosattiAlan CoxJuan J. Quintela

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"

 

 

 

 

 

 

Sharon And Joy
 

Kernel Traffic is grateful to be developed on a computer donated by Professor Greg Benson and Professor Allan Cruse in the Department of Computer Science at the University of San Francisco. This is the same department that invented FlashMob Computing. Kernel Traffic is hosted by the generous folks at kernel.org. All pages on this site are copyright their original authors, and distributed under the terms of the GNU General Public License version 2.0.