|| ||Linus Torvalds <email@example.com>|
|| ||Ingo Molnar <firstname.lastname@example.org>|
|| ||Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only
|| ||Tue, 4 Mar 2008 09:19:36 -0800 (PST)|
|| ||Pavel Roskin <email@example.com>, Zan Lynx <firstname.lastname@example.org>,
Jon Masters <email@example.com>,
Rusty Russell <firstname.lastname@example.org>,
Greg Kroah-Hartman <email@example.com>|
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
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
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.