* [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols @ 2008-02-28 22:11 Pavel Roskin 2008-02-28 23:25 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-28 22:11 UTC (permalink / raw) To: linux-kernel, Linus Torvalds; +Cc: Jon Masters, Rusty Russell 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 <proski@gnu.org> --- 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 ^ permalink raw reply related [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-28 22:11 [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Pavel Roskin @ 2008-02-28 23:25 ` Linus Torvalds 2008-02-29 6:20 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-28 23:25 UTC (permalink / raw) To: Pavel Roskin; +Cc: linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-28 23:25 ` Linus Torvalds @ 2008-02-29 6:20 ` Pavel Roskin 2008-02-29 16:08 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 6:20 UTC (permalink / raw) To: Linus Torvalds; +Cc: linux-kernel, Jon Masters, Rusty Russell Quoting Linus Torvalds <torvalds@linux-foundation.org>: > 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 6:20 ` Pavel Roskin @ 2008-02-29 16:08 ` Linus Torvalds 2008-02-29 16:54 ` Chris Friesen 2008-02-29 16:59 ` Zan Lynx 0 siblings, 2 replies; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 16:08 UTC (permalink / raw) To: Pavel Roskin; +Cc: linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:08 ` Linus Torvalds @ 2008-02-29 16:54 ` Chris Friesen 2008-02-29 17:06 ` Linus Torvalds 2008-03-06 14:56 ` David Woodhouse 2008-02-29 16:59 ` Zan Lynx 1 sibling, 2 replies; 39+ messages in thread From: Chris Friesen @ 2008-02-29 16:54 UTC (permalink / raw) To: Linus Torvalds; +Cc: Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:54 ` Chris Friesen @ 2008-02-29 17:06 ` Linus Torvalds 2008-02-29 17:59 ` Chris Friesen 2008-03-06 14:56 ` David Woodhouse 1 sibling, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 17:06 UTC (permalink / raw) To: Chris Friesen; +Cc: Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 17:06 ` Linus Torvalds @ 2008-02-29 17:59 ` Chris Friesen 0 siblings, 0 replies; 39+ messages in thread From: Chris Friesen @ 2008-02-29 17:59 UTC (permalink / raw) To: Linus Torvalds; +Cc: Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:54 ` Chris Friesen 2008-02-29 17:06 ` Linus Torvalds @ 2008-03-06 14:56 ` David Woodhouse 1 sibling, 0 replies; 39+ messages in thread From: David Woodhouse @ 2008-03-06 14:56 UTC (permalink / raw) To: Chris Friesen Cc: Linus Torvalds, Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:08 ` Linus Torvalds 2008-02-29 16:54 ` Chris Friesen @ 2008-02-29 16:59 ` Zan Lynx 2008-02-29 17:07 ` Linus Torvalds 2008-02-29 17:18 ` Jon Masters 1 sibling, 2 replies; 39+ messages in thread From: Zan Lynx @ 2008-02-29 16:59 UTC (permalink / raw) To: Linus Torvalds; +Cc: Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell [-- Attachment #1: Type: text/plain, Size: 551 bytes --] 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 <zlynx@acm.org> [-- Attachment #2: This is a digitally signed message part --] [-- Type: application/pgp-signature, Size: 189 bytes --] ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:59 ` Zan Lynx @ 2008-02-29 17:07 ` Linus Torvalds 2008-02-29 17:20 ` Pavel Roskin 2008-02-29 17:18 ` Jon Masters 1 sibling, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 17:07 UTC (permalink / raw) To: Zan Lynx; +Cc: Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 17:07 ` Linus Torvalds @ 2008-02-29 17:20 ` Pavel Roskin 2008-02-29 17:33 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 17:20 UTC (permalink / raw) To: Linus Torvalds; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 17:20 ` Pavel Roskin @ 2008-02-29 17:33 ` Linus Torvalds 2008-02-29 19:39 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 17:33 UTC (permalink / raw) To: Pavel Roskin; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 17:33 ` Linus Torvalds @ 2008-02-29 19:39 ` Pavel Roskin 2008-02-29 19:53 ` Linus Torvalds ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 19:39 UTC (permalink / raw) To: Linus Torvalds; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 19:39 ` Pavel Roskin @ 2008-02-29 19:53 ` Linus Torvalds 2008-02-29 20:08 ` Pavel Roskin 2008-02-29 20:17 ` John W. Linville 2008-02-29 21:15 ` Ingo Molnar 2 siblings, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 19:53 UTC (permalink / raw) To: Pavel Roskin; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 19:53 ` Linus Torvalds @ 2008-02-29 20:08 ` Pavel Roskin 2008-02-29 20:28 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 20:08 UTC (permalink / raw) To: Linus Torvalds; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:08 ` Pavel Roskin @ 2008-02-29 20:28 ` Linus Torvalds 2008-02-29 21:13 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: Linus Torvalds @ 2008-02-29 20:28 UTC (permalink / raw) To: Pavel Roskin; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:28 ` Linus Torvalds @ 2008-02-29 21:13 ` Pavel Roskin 0 siblings, 0 replies; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 21:13 UTC (permalink / raw) To: Linus Torvalds; +Cc: Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 19:39 ` Pavel Roskin 2008-02-29 19:53 ` Linus Torvalds @ 2008-02-29 20:17 ` John W. Linville 2008-02-29 20:40 ` David Newall 2008-02-29 20:44 ` Pavel Roskin 2008-02-29 21:15 ` Ingo Molnar 2 siblings, 2 replies; 39+ messages in thread From: John W. Linville @ 2008-02-29 20:17 UTC (permalink / raw) To: Pavel Roskin Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 linville@tuxdriver.com ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:17 ` John W. Linville @ 2008-02-29 20:40 ` David Newall 2008-02-29 20:59 ` Pavel Roskin 2008-02-29 20:44 ` Pavel Roskin 1 sibling, 1 reply; 39+ messages in thread From: David Newall @ 2008-02-29 20:40 UTC (permalink / raw) To: John W. Linville Cc: Pavel Roskin, Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:40 ` David Newall @ 2008-02-29 20:59 ` Pavel Roskin 2008-02-29 21:08 ` David Newall 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 20:59 UTC (permalink / raw) To: David Newall Cc: John W. Linville, Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:59 ` Pavel Roskin @ 2008-02-29 21:08 ` David Newall 2008-02-29 22:17 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: David Newall @ 2008-02-29 21:08 UTC (permalink / raw) To: Pavel Roskin Cc: John W. Linville, Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 21:08 ` David Newall @ 2008-02-29 22:17 ` Pavel Roskin 2008-03-01 8:15 ` David Newall 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 22:17 UTC (permalink / raw) To: David Newall Cc: John W. Linville, Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 22:17 ` Pavel Roskin @ 2008-03-01 8:15 ` David Newall 0 siblings, 0 replies; 39+ messages in thread From: David Newall @ 2008-03-01 8:15 UTC (permalink / raw) To: Pavel Roskin Cc: John W. Linville, Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 20:17 ` John W. Linville 2008-02-29 20:40 ` David Newall @ 2008-02-29 20:44 ` Pavel Roskin 1 sibling, 0 replies; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 20:44 UTC (permalink / raw) To: John W. Linville Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 19:39 ` Pavel Roskin 2008-02-29 19:53 ` Linus Torvalds 2008-02-29 20:17 ` John W. Linville @ 2008-02-29 21:15 ` Ingo Molnar 2008-02-29 22:31 ` Pavel Roskin 2 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2008-02-29 21:15 UTC (permalink / raw) To: Pavel Roskin Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 21:15 ` Ingo Molnar @ 2008-02-29 22:31 ` Pavel Roskin 2008-03-03 10:57 ` Ingo Molnar 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-02-29 22:31 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell On Fri, 2008-02-29 at 22:15 +0100, Ingo Molnar wrote: > * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 22:31 ` Pavel Roskin @ 2008-03-03 10:57 ` Ingo Molnar 2008-03-04 5:37 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2008-03-03 10:57 UTC (permalink / raw) To: Pavel Roskin Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-03 10:57 ` Ingo Molnar @ 2008-03-04 5:37 ` Pavel Roskin 2008-03-04 12:57 ` Ingo Molnar 0 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-03-04 5:37 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell Quoting Ingo Molnar <mingo@elte.hu>: > > * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 5:37 ` Pavel Roskin @ 2008-03-04 12:57 ` Ingo Molnar 2008-03-04 17:19 ` Linus Torvalds 0 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2008-03-04 12:57 UTC (permalink / raw) To: Pavel Roskin Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 12:57 ` Ingo Molnar @ 2008-03-04 17:19 ` Linus Torvalds 2008-03-04 17:38 ` Greg KH ` (2 more replies) 0 siblings, 3 replies; 39+ messages in thread From: Linus Torvalds @ 2008-03-04 17:19 UTC (permalink / raw) To: Ingo Molnar Cc: Pavel Roskin, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 17:19 ` Linus Torvalds @ 2008-03-04 17:38 ` Greg KH 2008-03-04 17:45 ` Pavel Roskin 2008-03-04 20:51 ` Ingo Molnar 2 siblings, 0 replies; 39+ messages in thread From: Greg KH @ 2008-03-04 17:38 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Pavel Roskin, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 17:19 ` Linus Torvalds 2008-03-04 17:38 ` Greg KH @ 2008-03-04 17:45 ` Pavel Roskin 2008-03-04 21:20 ` Ingo Molnar 2008-03-04 20:51 ` Ingo Molnar 2 siblings, 1 reply; 39+ messages in thread From: Pavel Roskin @ 2008-03-04 17:45 UTC (permalink / raw) To: Linus Torvalds Cc: Ingo Molnar, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 17:45 ` Pavel Roskin @ 2008-03-04 21:20 ` Ingo Molnar 2008-03-04 23:23 ` Pavel Roskin 0 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2008-03-04 21:20 UTC (permalink / raw) To: Pavel Roskin Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 21:20 ` Ingo Molnar @ 2008-03-04 23:23 ` Pavel Roskin 0 siblings, 0 replies; 39+ messages in thread From: Pavel Roskin @ 2008-03-04 23:23 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman On Tue, 2008-03-04 at 22:20 +0100, Ingo Molnar wrote: > * Pavel Roskin <proski@gnu.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 17:19 ` Linus Torvalds 2008-03-04 17:38 ` Greg KH 2008-03-04 17:45 ` Pavel Roskin @ 2008-03-04 20:51 ` Ingo Molnar 2008-03-04 23:25 ` Jiri Kosina 2 siblings, 1 reply; 39+ messages in thread From: Ingo Molnar @ 2008-03-04 20:51 UTC (permalink / raw) To: Linus Torvalds Cc: Pavel Roskin, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman * Linus Torvalds <torvalds@linux-foundation.org> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 20:51 ` Ingo Molnar @ 2008-03-04 23:25 ` Jiri Kosina 2008-03-05 13:21 ` Ingo Molnar 0 siblings, 1 reply; 39+ messages in thread From: Jiri Kosina @ 2008-03-04 23:25 UTC (permalink / raw) To: Ingo Molnar Cc: Linus Torvalds, Pavel Roskin, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-03-04 23:25 ` Jiri Kosina @ 2008-03-05 13:21 ` Ingo Molnar 0 siblings, 0 replies; 39+ messages in thread From: Ingo Molnar @ 2008-03-05 13:21 UTC (permalink / raw) To: Jiri Kosina Cc: Linus Torvalds, Pavel Roskin, Zan Lynx, linux-kernel, Jon Masters, Rusty Russell, Greg Kroah-Hartman * Jiri Kosina <jkosina@suse.cz> 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 16:59 ` Zan Lynx 2008-02-29 17:07 ` Linus Torvalds @ 2008-02-29 17:18 ` Jon Masters 2008-02-29 21:55 ` Adrian Bunk 1 sibling, 1 reply; 39+ messages in thread From: Jon Masters @ 2008-02-29 17:18 UTC (permalink / raw) To: Zan Lynx Cc: Linus Torvalds, Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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. ^ permalink raw reply [flat|nested] 39+ messages in thread
* Re: [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols 2008-02-29 17:18 ` Jon Masters @ 2008-02-29 21:55 ` Adrian Bunk 0 siblings, 0 replies; 39+ messages in thread From: Adrian Bunk @ 2008-02-29 21:55 UTC (permalink / raw) To: Jon Masters Cc: Zan Lynx, Linus Torvalds, Pavel Roskin, linux-kernel, Jon Masters, Rusty Russell 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 ^ permalink raw reply [flat|nested] 39+ messages in thread
end of thread, other threads:[~2008-03-06 14:57 UTC | newest] Thread overview: 39+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-02-28 22:11 [PATCH 2.6.25] module: allow ndiswrapper to use GPL-only symbols Pavel Roskin 2008-02-28 23:25 ` Linus Torvalds 2008-02-29 6:20 ` Pavel Roskin 2008-02-29 16:08 ` Linus Torvalds 2008-02-29 16:54 ` Chris Friesen 2008-02-29 17:06 ` Linus Torvalds 2008-02-29 17:59 ` Chris Friesen 2008-03-06 14:56 ` David Woodhouse 2008-02-29 16:59 ` Zan Lynx 2008-02-29 17:07 ` Linus Torvalds 2008-02-29 17:20 ` Pavel Roskin 2008-02-29 17:33 ` Linus Torvalds 2008-02-29 19:39 ` Pavel Roskin 2008-02-29 19:53 ` Linus Torvalds 2008-02-29 20:08 ` Pavel Roskin 2008-02-29 20:28 ` Linus Torvalds 2008-02-29 21:13 ` Pavel Roskin 2008-02-29 20:17 ` John W. Linville 2008-02-29 20:40 ` David Newall 2008-02-29 20:59 ` Pavel Roskin 2008-02-29 21:08 ` David Newall 2008-02-29 22:17 ` Pavel Roskin 2008-03-01 8:15 ` David Newall 2008-02-29 20:44 ` Pavel Roskin 2008-02-29 21:15 ` Ingo Molnar 2008-02-29 22:31 ` Pavel Roskin 2008-03-03 10:57 ` Ingo Molnar 2008-03-04 5:37 ` Pavel Roskin 2008-03-04 12:57 ` Ingo Molnar 2008-03-04 17:19 ` Linus Torvalds 2008-03-04 17:38 ` Greg KH 2008-03-04 17:45 ` Pavel Roskin 2008-03-04 21:20 ` Ingo Molnar 2008-03-04 23:23 ` Pavel Roskin 2008-03-04 20:51 ` Ingo Molnar 2008-03-04 23:25 ` Jiri Kosina 2008-03-05 13:21 ` Ingo Molnar 2008-02-29 17:18 ` Jon Masters 2008-02-29 21:55 ` Adrian Bunk
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).