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