A change after 2.6.24 broke ndiswrapper by accidentally removing its
access to GPL-only symbols. Revert that change and add comments about
the reasons why ndiswrapper and driverloader are treated in a special
way.
Signed-off-by: Pavel Roskin <[email protected]>
---
kernel/module.c | 9 ++++++++-
1 files changed, 8 insertions(+), 1 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 901cd6a..a11f523 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1933,8 +1933,15 @@ static struct module *load_module(void __user *umod,
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
+ /*
+ * ndiswrapper is under GPL by itself, but loads proprietary modules.
+ * Don't use add_taint_module(), as it would prevent ndiswrapper from
+ * using GPL-only symbols it needs.
+ */
if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+ add_taint(TAINT_PROPRIETARY_MODULE);
+
+ /* driverloader was caught wrongly pretending to be under GPL */
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
--
Regards,
Pavel Roskin
On Thu, 28 Feb 2008, Pavel Roskin wrote:
>
> A change after 2.6.24 broke ndiswrapper by accidentally removing its
> access to GPL-only symbols. Revert that change and add comments about
> the reasons why ndiswrapper and driverloader are treated in a special
> way.
I'm not seeing why ndiswrapper should be treated separately.
If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.
So if ndiswrapper needs GPL-only symbols, you'd better ask the people who
made those symbols GPL-only whether they could be made available to
ndiswrapper.
ndiswrapper itself is *not* compatible with the GPL. Trying to claim that
ndiswrapper somehow itself is GPL'd even though it then loads modules that
aren't is stupid and pointless. Clearly it just re-exports those GPLONLY
functions to code that is *not* GPL'd.
Linus
Quoting Linus Torvalds <[email protected]>:
> On Thu, 28 Feb 2008, Pavel Roskin wrote:
>>
>> A change after 2.6.24 broke ndiswrapper by accidentally removing its
>> access to GPL-only symbols. Revert that change and add comments about
>> the reasons why ndiswrapper and driverloader are treated in a special
>> way.
>
> I'm not seeing why ndiswrapper should be treated separately.
It is already treated separately, and has been for a long time. Since
ndiswrapper taints itself when it loads a proprietary NDIS module, I
don't think any special treatment is needed anymore, but that's beyond
my point.
All I'm trying to do it to revert a patch that, as its author
admitted, had unexpected consequences:
http://kerneltrap.org/mailarchive/linux-kernel/2008/1/30/648044
> If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.
This is not the original intention of GPLONLY. GPLONLY exists to
prevent loading of modules that are proprietary, but can be considered
to be Linux derivatives due to their use of Linux specific API.
In case of ndiswrapper, there is no question that ndiswrapper is a
Linux derivative, but it's under GPL. Yet the proprietary modules are
not Linux derivatives because they don't use Linux API. In fact, they
were never intended to run on Linux.
By using GPLONLY to exclude ndiswrapper, you would give GPLONLY an
additional meaning, namely functions that are not available to
ndiswrapper.
> So if ndiswrapper needs GPL-only symbols, you'd better ask the people who
> made those symbols GPL-only whether they could be made available to
> ndiswrapper.
That would mean that I would have to ask those symbols to be opened to
proprietary Linux kernel modules as well, which is not my intention.
> ndiswrapper itself is *not* compatible with the GPL. Trying to claim that
> ndiswrapper somehow itself is GPL'd even though it then loads modules that
> aren't is stupid and pointless. Clearly it just re-exports those GPLONLY
> functions to code that is *not* GPL'd.
Simple re-exporting would be useless. It's a wrapper that isolates
NDIS API from Linux API. Anything Linux specific is in ndiswrapper
itself. The proprietary modules call only NDIS functions.
I believe, the license is a choice of the copyright holders. Apart
from that, I don't feel qualified to discuss any legal matters.
--
Regards,
Pavel Roskin
On Fri, 29 Feb 2008, Pavel Roskin wrote:
> >
> > I'm not seeing why ndiswrapper should be treated separately.
>
> It is already treated separately, and has been for a long time.
No, I mean "separately from the thing it loads".
It loads non-GPL code, it is non-GPL.
> > If it loads non-GPL modules, it shouldn't be able to use GPLONLY symbols.
>
> This is not the original intention of GPLONLY. GPLONLY exists to prevent
> loading of modules that are proprietary, but can be considered to be Linux
> derivatives due to their use of Linux specific API.
Exactly. And ndiswrapper loads proprietary modules.
You're not following the argument. There was a reason ndiswrapper was
marked for tainting.
Linus
Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
>
>>>I'm not seeing why ndiswrapper should be treated separately.
>>
>>It is already treated separately, and has been for a long time.
>
>
> No, I mean "separately from the thing it loads".
>
> It loads non-GPL code, it is non-GPL.
But the GPL only applies to derivative works. Given that ndiswrapper
loads binaries designed for another OS, doesn't that mean that it is
unlikely that the binaries would be impacted by the GPL?
So the portion that is a derivative work (ndiswrapper itself) is GPL,
and it loads something that is clearly not a derivative work. From a
licensing standpoint how is this different than an open-source driver
loading a proprietary firmware?
Once ndiswrapper loads the binary blob the kernel should be considered
tainted from a debuggability standpoint, but I have some sympathy for an
argument suggesting that ndiswrapper should be able to use GPLONLY symbols.
Chris
On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
[cut]
> It loads non-GPL code, it is non-GPL.
[cut]
> Exactly. And ndiswrapper loads proprietary modules.
The Linux kernel itself will load proprietary modules. It does not as a
general rule, but it will.
Is the Linux kernel then not GPL? No. This argument doesn't work,
Linus.
There exists at least one GPL NDIS driver[1]. How about if everyone
involved piously promises to load it at least once?
[1] http://cipe-win32.sourceforge.net/
--
Zan Lynx <[email protected]>
On Fri, 29 Feb 2008, Chris Friesen wrote:
>
> But the GPL only applies to derivative works. Given that ndiswrapper loads
> binaries designed for another OS, doesn't that mean that it is unlikely that
> the binaries would be impacted by the GPL?
But that's what GPLONLY means.
What's so hard to understand? The driver may not be a derivative work, but
it sure as hell isn't GPL'd.
So stop blathering. ndiswrapper has one purpose, and one purpose only: to
load non-GPL'd code. So OF COURSE it shouldn't touch GPLONLY functions.
Linus
On Fri, 29 Feb 2008, Zan Lynx wrote:
>
> The Linux kernel itself will load proprietary modules. It does not as a
> general rule, but it will.
.. and it doesn't export GPLONLY modules to them.
How stupid do you have to be to not understand that?
Linus
On Fri, 2008-02-29 at 09:59 -0700, Zan Lynx wrote:
> On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
> [cut]
> > It loads non-GPL code, it is non-GPL.
> [cut]
> > Exactly. And ndiswrapper loads proprietary modules.
>
> The Linux kernel itself will load proprietary modules. It does not as a
> general rule, but it will.
And when that happens, the same taint flag will be set. Your argument is
a non-argument :)
But anyway...
FWIW, I wasn't actually trying to start this debate with the patch I
sent before - I was simply correcting what seemed to be "obviously"
broken logic in module.c for handling ndiswrapper[0]. I was auditing the
taint flags for a backport to another kernel, and noticed this. Having
said that, there would seem to be two directions this can now go in:
*). Back out this patch, go back to previous situation. But then there's
still special case logic for ndiswrapper, and it's not really doing what
people would likely consider the "right" thing with its tainting then. I
again suggest that ndiswrapper would need to be sure to set the taint
flags itself, which would be an alternative to "policing" it.
*). Keep this patch. And potentially add some more for other similar
shim layers - I can think of a certain graphics driver that might
qualify for similar treatment, if one wants to go there. But I might
need to find a tailor specializing in *really* fire retardant pants
before I think of being the one who submits that patch.
I've no idea what "the right thing" is here, but many seem to think it
involves backing out this patch (the most compelling argument given so
far is that it might force ndiswrapper simply to change its name, and
that there's no clear idea if the kernel should be enforcing ideology).
Since we've brought it up, one good thing I would like to see come of
this perhaps is a clearer understanding of what the kernel should and
should not be doing in terms of "license compliance enforcement". We
have had lots of talk, but perhaps a "policy" document is worthwhile.
Jon.
[0] If this is reverted, please do stick in a reference to:
http://lwn.net/Articles/205644/ to avoid repeats.
On Fri, 2008-02-29 at 09:07 -0800, Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Zan Lynx wrote:
> >
> > The Linux kernel itself will load proprietary modules. It does not as a
> > general rule, but it will.
>
> .. and it doesn't export GPLONLY modules to them.
>
> How stupid do you have to be to not understand that?
Actually, it's a flawed comparison. The only thing ndiswrapper exports
to NDIS modules is NDIS API. GPLONLY symbols are only used to implement
that API in the code that's under GPL. That's the code you can fork,
change and redistribute.
--
Regards,
Pavel Roskin
On Fri, 29 Feb 2008, Pavel Roskin wrote:
>
> Actually, it's a flawed comparison. The only thing ndiswrapper exports
> to NDIS modules is NDIS API. GPLONLY symbols are only used to implement
> that API in the code that's under GPL. That's the code you can fork,
> change and redistribute.
.. and it's stuill just a wrapper.
A fairly thick one, but still...
More importantly, none of the people arguing against this at all even
reacted to my suggestion for how to fix things *properly* in my original
email. Which just means that you're apparently not interested in actually
fixing this, you're just trying to disagree about some interpretation of
GPLONLY.
In other words: the next person who can't even be bothered to tell what
symbols are involved and why they haven't asked whether those symbols
could instead be relaxed, automaticaly will go into my "flamers" filter,
and just stay there. Then you can complain as much as you like, and I'll
never see it.
Linus
Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Chris Friesen wrote:
>
>>But the GPL only applies to derivative works. Given that ndiswrapper loads
>>binaries designed for another OS, doesn't that mean that it is unlikely that
>>the binaries would be impacted by the GPL?
>
>
> But that's what GPLONLY means.
>
> What's so hard to understand? The driver may not be a derivative work, but
> it sure as hell isn't GPL'd.
I hope this won't dump me into the flamers filter....but here goes:
If the intent of the GPLONLY export is really to keep the symbol from
being used by non-GPL code then I agree that ndiswrapper shouldn't be
able to use them.
However, you yourself wrote something stating otherwise:
(http://groups.google.ca/group/linux.kernel/msg/0066655bb1be1e4c):
'I think we _can_ do things where we give clear hints to people that "we
think this is such an internal Linux thing that you simply cannot use
this without being considered a derived work".....So I personally don't
see EXPORT_SYMBOL_GPL() to be a "technical measure", I see it as being
"documentation".'
Under that interpretation, ndiswrapper should be able to make use of
GPLONLY symbols because the binary blobs are clearly not derivative works.
Chris
On Fri, 2008-02-29 at 09:33 -0800, Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> >
> > Actually, it's a flawed comparison. The only thing ndiswrapper exports
> > to NDIS modules is NDIS API. GPLONLY symbols are only used to implement
> > that API in the code that's under GPL. That's the code you can fork,
> > change and redistribute.
>
> .. and it's stuill just a wrapper.
>
> A fairly thick one, but still...
So it the Linux syscall interface. It's a wrapper around the kernel
internals, including GPLONLY symbols. Yet some userspace programs are
proprietary.
> More importantly, none of the people arguing against this at all even
> reacted to my suggestion for how to fix things *properly* in my original
> email. Which just means that you're apparently not interested in actually
> fixing this, you're just trying to disagree about some interpretation of
> GPLONLY.
I'm actually interested in fixing this, or I would not have sent a
patch.
> In other words: the next person who can't even be bothered to tell what
> symbols are involved and why they haven't asked whether those symbols
> could instead be relaxed, automaticaly will go into my "flamers" filter,
> and just stay there. Then you can complain as much as you like, and I'll
> never see it.
Well, here's the list
__create_workqueue_key
destroy_workqueue
flush_workqueue
queue_work
task_nice
usb_alloc_urb
usb_buffer_alloc
usb_buffer_free
usb_clear_halt
usb_control_msg
usb_deregister
usb_free_urb
usb_get_current_frame_number
usb_get_descriptor
usb_get_status
usb_ifnum_to_if
usb_init_urb
usb_kill_urb
usb_lock_device_for_reset
usb_register_driver
usb_reset_configuration
usb_reset_device
usb_set_interface
usb_submit_urb
usb_unlink_urb
I already know what USB folks will say. They want proprietary drivers
to be in the userspace. I doubt ndiswrapper will ever be ported to the
userspace. It's much more likely that some other approach will be used.
--
Regards,
Pavel Roskin
On Fri, 29 Feb 2008, Pavel Roskin wrote:
>
> I already know what USB folks will say. They want proprietary drivers
> to be in the userspace. I doubt ndiswrapper will ever be ported to the
> userspace. It's much more likely that some other approach will be used.
If that's the case, then talk to the USB people. Maybe they are ok with
wrapping them in GPL wrappers. But it sounds like they would prefer the
stricter GPLONLY meaning (ie no ndiswrapper), and it's their code.
Linus
On Fri, 2008-02-29 at 11:53 -0800, Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> >
> > I already know what USB folks will say. They want proprietary drivers
> > to be in the userspace. I doubt ndiswrapper will ever be ported to the
> > userspace. It's much more likely that some other approach will be used.
>
> If that's the case, then talk to the USB people. Maybe they are ok with
> wrapping them in GPL wrappers. But it sounds like they would prefer the
> stricter GPLONLY meaning (ie no ndiswrapper), and it's their code.
This still leaves us with the workqueue interface:
__create_workqueue_key
destroy_workqueue
flush_workqueue
queue_work
ndiswrapper has its own workqueue implementation, but it would be great
to avoid code duplication.
As for task_nice(), it's strange that task_nice() is GPLONLY, but
set_user_nice() is not. Anyway, it can probably be worked around.
--
Regards,
Pavel Roskin
On Fri, 29 Feb 2008, Pavel Roskin wrote:
>
> This still leaves us with the workqueue interface:
>
> __create_workqueue_key
> destroy_workqueue
> flush_workqueue
> queue_work
Hmm. Personally, I don't see those as being a big issue, but they've been
marked GPL-only for a long while.
The thing is, I personally don't mind, and I think "derived code" is what
matters, but others disagree, and quite frankly, I'm not going to force
them - I have my _personal_ beliefs, but hey, others have theirs.
So you really need to talk to not me, but to the people who actually wrote
and maintain that code. When they come back and say "yeah, we think
ndiswrapper is a special case and we're ok with it", I'll happily either
mark those things non-GPL or just mark ndiswrapper special in the module
loader again.
Quite frankly, I don't care about ndiswrapper enough (at all) to push this
along in the least.
Linus
On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
> I doubt ndiswrapper will ever be ported to the
> userspace. It's much more likely that some other approach will be used.
Maybe it should be -- that might solve a lot of problems.
--
John W. Linville
[email protected]
John W. Linville wrote:
> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
>
>> I doubt ndiswrapper will ever be ported to the
>> userspace. It's much more likely that some other approach will be used.
>>
>
> Maybe it should be -- that might solve a lot of problems
Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".
How stupid do you have to be to not see that it will be fixed in any way
necessary.
On Fri, 2008-02-29 at 15:17 -0500, John W. Linville wrote:
> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
>
> > I doubt ndiswrapper will ever be ported to the
> > userspace. It's much more likely that some other approach will be used.
>
> Maybe it should be -- that might solve a lot of problems.
I doubt it can be done for PCI due to DMA use by some of the drivers.
Perhaps it could be done for USB, but I doubt anyone will bother.
--
Regards,
Pavel Roskin
On Sat, 2008-03-01 at 07:10 +1030, David Newall wrote:
> John W. Linville wrote:
> > On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
> >
> >> I doubt ndiswrapper will ever be ported to the
> >> userspace. It's much more likely that some other approach will be used.
> >>
> >
> > Maybe it should be -- that might solve a lot of problems
>
> Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".
>
> How stupid do you have to be to not see that it will be fixed in any way
> necessary.
I'm quite sure that something like that is going to be the short term
fix. Still, it would be nice to have a more long term solution, the one
that tries to resolve the tensions rather than hide them. I'm not sure
it's possible, but just trying to negotiate could help find
understanding.
--
Regards,
Pavel Roskin
Pavel Roskin wrote:
> On Sat, 2008-03-01 at 07:10 +1030, David Newall wrote:
>
>> John W. Linville wrote:
>>
>>> On Fri, Feb 29, 2008 at 02:39:38PM -0500, Pavel Roskin wrote:
>>>
>>>
>>>> I doubt ndiswrapper will ever be ported to the
>>>> userspace. It's much more likely that some other approach will be used.
>>>>
>>>>
>>> Maybe it should be -- that might solve a lot of problems
>>>
>> Maybe it's time to rename it from "ndiswrapper" to "NdisWrapper".
>>
>> How stupid do you have to be to not see that it will be fixed in any way
>> necessary.
>>
>
> I'm quite sure that something like that is going to be the short term
> fix. Still, it would be nice to have a more long term solution, the one
> that tries to resolve the tensions rather than hide them. I'm not sure
> it's possible, but just trying to negotiate could help find
> understanding
I think there's a political agenda, and that's something that nobody can
solve. The simplest solution is to change the name it uses on a regular
basis, and that something relatively unimportant. People will still
call it ndiswrapper, but it will identify itself to the kernel as
wrappythingy, and then ndisthingy, and then wrapndis. Heck, make it
purely random. Solve the problem for all time.
It's a stupid problem promulgated by stupid people, and I use the word
"stupid" in it's most pejorative sense.
On Fri, 2008-02-29 at 12:28 -0800, Linus Torvalds wrote:
>
> On Fri, 29 Feb 2008, Pavel Roskin wrote:
> >
> > This still leaves us with the workqueue interface:
> >
> > __create_workqueue_key
> > destroy_workqueue
> > flush_workqueue
> > queue_work
>
> Hmm. Personally, I don't see those as being a big issue, but they've been
> marked GPL-only for a long while.
>
> The thing is, I personally don't mind, and I think "derived code" is what
> matters, but others disagree, and quite frankly, I'm not going to force
> them - I have my _personal_ beliefs, but hey, others have theirs.
>
> So you really need to talk to not me, but to the people who actually wrote
> and maintain that code.
As far as I can tell, those people have never tried to prevent
ndiswrapper from using their code. Both times ndiswrapper was prevented
from using GPLONLY symbols, it was done unintentionally.
> When they come back and say "yeah, we think
> ndiswrapper is a special case and we're ok with it", I'll happily either
> mark those things non-GPL or just mark ndiswrapper special in the module
> loader again.
OK, I'll keep it in mind in case such approach actually becomes
necessary.
--
Regards,
Pavel Roskin
* Pavel Roskin <[email protected]> wrote:
> I already know what USB folks will say. They want proprietary drivers
> to be in the userspace. I doubt ndiswrapper will ever be ported to
> the userspace. It's much more likely that some other approach will be
> used.
btw., what are the technical reasons why ndiswrapper cannot be done in
userspace, much like the (wildly successful) FUSE concept?
what's the main hardware access method of ndiswrapper - only PIO, or
mmio as well? In the former case, ioperm() should work, in the latter
case, mmap()ing the device aperture should work.
Frankly, it would be a great approach for the following reason: it would
be _far_ easier for people to write a proper free driver, if the NDIS
driver was in user-space, in a nicely debuggable, traceable, observable
environment. I dont really see what the technical difficulties there are
here.
Ingo
On Fri, Feb 29, 2008 at 12:18:12PM -0500, Jon Masters wrote:
>...
> *). Keep this patch. And potentially add some more for other similar
> shim layers - I can think of a certain graphics driver that might
> qualify for similar treatment, if one wants to go there. But I might
> need to find a tailor specializing in *really* fire retardant pants
> before I think of being the one who submits that patch.
>...
If all that's missing for getting such a patch included is submitting it
I would even do it with my normal pants on. [1]
I would leave the *really* fire retardant pants for the case that
someone will ever try some "are binary modules legal" case at court by
suing people operating ftp mirrors of Debian non-free and similar
repositories of other distributions... [2,3]
> Jon.
>...
cu
Adrian
[1] no matter whether in the British or the American meaning of "pants"
[2] realistically, if these things will ever go to court, the person
suing might not want to choose some billion Dollar US company
but some local private person or university as defendant
[3] like e.g. Caldera turning into SCO and a Linux developer fired by
Novell yesterday being hired by Microsoft tomorrow life changes
fast, and one of the many copyright holders of the kernel might some
day find some reason why he wants to do this
--
"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed
On Sat, 2008-03-01 at 07:38 +1030, David Newall wrote:
> I think there's a political agenda, and that's something that nobody can
> solve. The simplest solution is to change the name it uses on a regular
> basis, and that something relatively unimportant. People will still
> call it ndiswrapper, but it will identify itself to the kernel as
> wrappythingy, and then ndisthingy, and then wrapndis. Heck, make it
> purely random. Solve the problem for all time.
If there is a political agenda, then LKML is the worst place to discuss
the details.
> It's a stupid problem promulgated by stupid people, and I use the word
> "stupid" in it's most pejorative sense.
It would be more useful if you counter specific arguments rather than
employ ad hominem attacks.
--
Regards,
Pavel Roskin
On Fri, 2008-02-29 at 22:15 +0100, Ingo Molnar wrote:
> * Pavel Roskin <[email protected]> wrote:
>
> > I already know what USB folks will say. They want proprietary drivers
> > to be in the userspace. I doubt ndiswrapper will ever be ported to
> > the userspace. It's much more likely that some other approach will be
> > used.
>
> btw., what are the technical reasons why ndiswrapper cannot be done in
> userspace, much like the (wildly successful) FUSE concept?
ndiswrapper contains essentially two drivers in one - PCI and USB. The
PCI driver uses DMA, which should be a strong argument for keeping it in
the kernel.
As for the USB driver, it may be possible, but some infrastructure may
still be missing.
ndiswrapper needs to register network devices. For wireless devices, it
needs to be a device with wireless extension support. I don't think
it's currently possible from the userspace.
> what's the main hardware access method of ndiswrapper - only PIO, or
> mmio as well? In the former case, ioperm() should work, in the latter
> case, mmap()ing the device aperture should work.
Both. I'm afraid DMA is the real problem here.
> Frankly, it would be a great approach for the following reason: it would
> be _far_ easier for people to write a proper free driver, if the NDIS
> driver was in user-space, in a nicely debuggable, traceable, observable
> environment. I dont really see what the technical difficulties there are
> here.
I agree that it would be great, but it's quite a lot of work.
--
Regards,
Pavel Roskin
Pavel Roskin wrote:
> On Sat, 2008-03-01 at 07:38 +1030, David Newall wrote:
>
>> It's a stupid problem promulgated by stupid people, and I use the word
>> "stupid" in it's most pejorative sense.
>>
>
> It would be more useful if you counter specific arguments rather than
> employ ad hominem attacks.
True. Somebody had just said something quite similar, which undoubtedly
is what brought the thought to mind. However, it is a stupid problem,
and all of the arguments have already been done to death. Nothing
remains to be said, and the sensible strategy now is just to work around
the stupid blocks and ignore any fools who care to howl. Also, working
around the blocks serves as a useful object lesson to everybody who has
forgotten that the point of the GPL is to provide freedom to innovate
and change, not to restrict it.
Just do it.
* Pavel Roskin <[email protected]> wrote:
> > btw., what are the technical reasons why ndiswrapper cannot be done
> > in userspace, much like the (wildly successful) FUSE concept?
>
> ndiswrapper contains essentially two drivers in one - PCI and USB.
> The PCI driver uses DMA, which should be a strong argument for keeping
> it in the kernel.
how exactly does it use DMA - how does it allocate the memory it later
on DMAs into, and how does it typically program that DMA target - is
there any control over that in the NDIS protocol - or will NDIS drivers
just write random addresses to the mmio space and then the hardware does
DMA to/from those addresses? [without the NDIS framework having any
knowledge about the encoding of those bits?]
on modern hardware it might even be possible to jail an ndiswrapper
driver to its own pages via the IOMMU.
Ingo
Quoting Ingo Molnar <[email protected]>:
>
> * Pavel Roskin <[email protected]> wrote:
>
>> > btw., what are the technical reasons why ndiswrapper cannot be done
>> > in userspace, much like the (wildly successful) FUSE concept?
>>
>> ndiswrapper contains essentially two drivers in one - PCI and USB.
>> The PCI driver uses DMA, which should be a strong argument for keeping
>> it in the kernel.
>
> how exactly does it use DMA - how does it allocate the memory it later
> on DMAs into, and how does it typically program that DMA target - is
> there any control over that in the NDIS protocol - or will NDIS drivers
> just write random addresses to the mmio space and then the hardware does
> DMA to/from those addresses? [without the NDIS framework having any
> knowledge about the encoding of those bits?]
Sorry for delay. I'm really not sure. The maintainer of ndiswrapper
is currently offline, and I'm just trying to take care of the basic
stuff.
All I can say is NdisMAllocateSharedMemory maps to
dma_alloc_coherent(), and there are some references to scatter-gather
lists. There is a call to dma_map_single(), which is ultimately
called by the Tx function net_dev->hard_start_xmit.
I understand there is some control from NDIS. At least it can request
memory available for DMA.
> on modern hardware it might even be possible to jail an ndiswrapper
> driver to its own pages via the IOMMU.
It's possible that ndiswrapper would support Vista drivers only on
x86_64, which should always have IOMMU, if I understand correctly.
But it would be nice to have proper support for older XP drivers on x86.
--
Regards,
Pavel Roskin
* Pavel Roskin <[email protected]> wrote:
>>> ndiswrapper contains essentially two drivers in one - PCI and USB.
>>> The PCI driver uses DMA, which should be a strong argument for
>>> keeping it in the kernel.
>>
>> how exactly does it use DMA - how does it allocate the memory it
>> later on DMAs into, and how does it typically program that DMA target
>> - is there any control over that in the NDIS protocol - or will NDIS
>> drivers just write random addresses to the mmio space and then the
>> hardware does DMA to/from those addresses? [without the NDIS
>> framework having any knowledge about the encoding of those bits?]
>
> Sorry for delay. I'm really not sure. The maintainer of ndiswrapper
> is currently offline, and I'm just trying to take care of the basic
> stuff.
>
> All I can say is NdisMAllocateSharedMemory maps to
> dma_alloc_coherent(), and there are some references to scatter-gather
> lists. There is a call to dma_map_single(), which is ultimately
> called by the Tx function net_dev->hard_start_xmit.
>
> I understand there is some control from NDIS. At least it can request
> memory available for DMA.
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?
you could try to create a syscall-ish API towards the kernel that allows
DMA, it would have the following functionality:
- allocate a piece of continuous memory and return its physical address
plus its linear address as well and map the linear address into the
user-space pagetables. This memory would be unfragmented on the
physical side.
you probably could even use/hack hugetlbfs right now to achieve
something very similar. (hugetlbfs pages are unfragmented 2MB
largepages)
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.
i think someone should really try to push a known-well-behaving NDIS
driver (for which a Linux driver exists too) down to user-space. NDIS
has been around since Netware so it's a pretty well-understood driver
model. And with an iommu it could all be made a safe sandbox as well (an
NDIS device could never exit its sandbox).
Ingo
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
On Tue, Mar 04, 2008 at 09:19:36AM -0800, Linus Torvalds wrote:
> 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.
I think ndiswrapper is a great hack from a technical point-of-view. But
yes, I also do not think it is a violation of the GPLv2 for the same
reasons you do.
> 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.
I have no objection to reverting that patch to have nidiswrapper access
to those symbols, especially as that is really the only way they will be
able to control USB devices (as you state, doing a network driver in
userspace doesn't really make sense.)
thanks,
greg k-h
On Tue, 2008-03-04 at 09:19 -0800, Linus Torvalds wrote:
> 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.
> 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.
> So asking people to make ndiswrapper be user-mode only is simply not
> realistic.
Agreed.
> 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.
> 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.
> 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.
> 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
* Linus Torvalds <[email protected]> wrote:
> 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.
yeah, i agree that putting it into userspace is quite insane.
it might possible to do it halfways sanely via existing arch/x86/kvm/
infrastructure though. VMX/SVM context will properly emulate the IRQ
flag so cli/sti will work fine, and as long as DMA is properly
quarantined via an iommu it might even not corrupt the rest of the
system. Right now KVM is tailored for full system emulation but there's
no strong reason why it couldnt emulate just a single hardware domain,
with an NDIS driver sitting in that domain - talking to the rest of the
system via hypercalls.
> 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.
the ugliest technical aspect of them being in the Linux host kernel is
that NDIS drivers are used to a larger kernel stack, so they very
frequently overflow the Linux kernel stack. Not sure whether recent
versions of ndiswrapper have solved this problem.
Ingo
* Pavel Roskin <[email protected]> wrote:
> 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.
task_nice() - it's trivial so feel free to send a patch that turns it
into EXPORT_SYMBOL().
Ingo
On Tue, 2008-03-04 at 22:20 +0100, Ingo Molnar wrote:
> * Pavel Roskin <[email protected]> wrote:
>
> > 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.
>
> task_nice() - it's trivial so feel free to send a patch that turns it
> into EXPORT_SYMBOL().
The recent discussion makes me nervous about sending any patches of such
kind. Instead of getting access task_nice(), ndiswrapper could lose
access to set_user_nice() or something else.
It's bad already that a mistaken commit has turned into a permanent
restriction for ndiswrapper after my intervention :-(
--
Regards,
Pavel Roskin
On Tue, 4 Mar 2008, Ingo Molnar wrote:
> > 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.
> yeah, i agree that putting it into userspace is quite insane.
> it might possible to do it halfways sanely via existing arch/x86/kvm/
> infrastructure though. VMX/SVM context will properly emulate the IRQ
> flag so cli/sti will work fine, and as long as DMA is properly
> quarantined via an iommu it might even not corrupt the rest of the
> system.
This definitely could be a [hackish] way to go. The remarkable drawback
is that it will not work on CPUs without virtualization extensions.
--
Jiri Kosina
SUSE Labs
* Jiri Kosina <[email protected]> wrote:
> On Tue, 4 Mar 2008, Ingo Molnar wrote:
>
> > > 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.
> > yeah, i agree that putting it into userspace is quite insane.
> > it might possible to do it halfways sanely via existing arch/x86/kvm/
> > infrastructure though. VMX/SVM context will properly emulate the IRQ
> > flag so cli/sti will work fine, and as long as DMA is properly
> > quarantined via an iommu it might even not corrupt the rest of the
> > system.
>
> This definitely could be a [hackish] way to go. The remarkable
> drawback is that it will not work on CPUs without virtualization
> extensions.
by the time it's implemented and trickles into distributions the
majority of PCs will have virtualization extensions.
Ingo
On Fri, 2008-02-29 at 10:54 -0600, Chris Friesen wrote:
> But the GPL only applies to derivative works.
Not entirely true -- or at least somewhat misleading as phrased.
There are cases where the GPL clearly states that it _does_ apply to
sections of code which are "independent and separate works in
themselves".
--
dwmw2