On Tue, 2008-03-04 at 09:19 -0800, Linus Torvalds wrote:

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

Agreed.

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

And even then, we need a network interface in the kernel, which would
possibly support wireless extensions.

And most importantly, I don't think anyone will bother rewriting
ndiswrapper.  It's a popular project amongst users, but it suffers from
little attention of developers.

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

Agreed.

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

Yes.

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

Nice to hear that.

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

To recap:

1) USB API
2) Workqueue API (there is a hackish replacement in ndiswrapper)
3) task_nice(), but I have a trivial workaround for that.

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

Let me explain my position.  Using of GPL-only symbols by ndiswrapper
has been tolerated for years.  The change was not even intended to stop
it.  It was a side effect.

As it stands now, I don't want to be in the position to ask anyone to
add extra support to recognize ndiswrapper or to have some ugly
EXPORT_SYMBOL_GPL_OR_NDISWRAPPER.

Believe me, I don't want to be uncooperative.  But I think I'll be in
the position to ask for exceptions for ndiswrapper only if somebody is
actively and _intentionally_ looking to prevent it from using GPL-only
symbols.  That's why if nothing changes in the kernel, ndiswrapper will
be renamed.  This way we'll see if anyone actually cares enough to block
ndiswrapper again.  And in this situation, I'll be in a better position
to ask authors of the workqueue API and USB for an explicit exception.

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