Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-onlysymbols

[Linus Torvalds]

On Tue, 4 Mar 2008, Ingo Molnar wrote:
> 
> so ... i suspect the requirement would be for 
> NdisMAllocateSharedMemory() to return a linear address that is DMA-able, 
> and to properly map it to a physical address via dma_map_single(). I can 
> see only one complication in pushing this to user-space: physical 
> fragmentation of allocations. What are the typical buffer sizes that 
> NDIS drivers request from the kernel? Is it frequently above 4K?

Ingo, i's simply not possible to put ndiswrapper in user-space sanely.

Drivers are drivers. They'll want (shared) interrupts, they want DMA, they 
want to do things like cli/sti. 

The USB drivers *may* be abstracted enough that they don't do any of that, 
but quite frankly, I doubt it.

> if the NDIS API is done halfways right, then there's no need for any of 
> these buffers to be in kernel-space and for the driver to run in kernel 
> space.

Don't be silly. When you claim this is the only way things are "halfway 
right", then none of the Linux kernel driver interfaces are even *close* 
to halfway right. Sure, the NDIS ABI has to b more abstracted than the 
Linux kernel one (because it's a binary ABI that survives over multiple 
Windows versions, not a source code API), but the fact is, NDIS is 
designed for kernel-mode, not user mode.

So asking people to make ndiswrapper be user-mode only is simply not 
realistic.

The question on the table is not whether we can make it user-mode 
(especially since no major kernel contributor is likely to even care 
enough to really help code anyway), but whether we should let ndiswrapper 
continue using GPLONLY symbols.

Quite frankly, my position on this has always been that the GPLv2 
explicitly covers _derived_ works only, and that very obviously a Windows 
driver isn't a derived work of the kernel. So as far as I'm concerned, 
ndiswrapper may be distasteful froma technical and support angle, but not 
against the license.

So I'm personally perfectly happy to say that we should revert that commit 
0aa5bd52d0c49ca56d24584c646e6544ccbb3dc9, but what I've wanted to hear 
from the very beginning was simply to get a list of symbols that currently 
clash, and hear from the people who maintain the symbols whether they 
really meant for that commit to be valid.

That's the only issue here. Not whether ndiswrapper could do a part of its 
job in user space (because the answer to that latter question is: no. 
Everything is "possible", of course, but realistically, that's simply not 
going to happen).

It sounds like there aren't that many symbols affected at the core: the 
workqueue stuff certainly isn't worth bothering about. The USB things that 
ndiswrapper wants is much more involved, and more likely to have issues, 
but I'm cc'ing Greg here to see.

IOW: I _personally_ don't think there are any license issues, but I do 
want to have the situation clear to people involved.

		Linus
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/