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

--

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

--

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:
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  
That would mean that I would have to ask those symbols to be opened to  
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

--

No, I mean "separately from the thing it loads".
Exactly. And ndiswrapper loads proprietary modules.
You're not following the argument. There was a reason ndiswrapper was

marked for tainting. 
			Linus

--

On Fri, 2008-02-29 at 08:08 -0800, Linus Torvalds wrote:
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/

--=20

Zan Lynx <zlynx@acm.org>

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

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

.. and it doesn't export GPLONLY modules to them.
How stupid do you have to be to not understand that?
		Linus

--

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

--

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

--

So it the Linux syscall interface.  It's a wrapper around the kernel

internals, including GPLONLY symbols.  Yet some userspace programs are
I'm actually interested in fixing this, or I would not have sent a
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

--

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

--

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
I agree that it would be great, but it's quite a lot of work.
--

Regards,

Pavel Roskin

--

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

--

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

--

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, 
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 abo...
[ message continues ]

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

--

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

by the time it's implemented and trickles into distributions the

majority of PCs will have virtualization extensions.
	Ingo

--

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
To recap:
1) USB API

2) Workqueue API (there is a hackish replacement in ndiswrapper)
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

--

task_nice() - it's trivial so feel free to send a patch that turns it

into EXPORT_SYMBOL().
	Ingo

--

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

--

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

--

Maybe it should be -- that might solve a lot of problems.
--

John W. Linville

linville@tuxdriver.com

--

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

--

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

--

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.

--

If there is a political agenda, then LKML is the worst place to discuss
It would be more useful if you counter specific arguments rather than

employ ad hominem attacks.
--

Regards,

Pavel Roskin

--

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.

--

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

--

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

--

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

--

As far as I can tell, those people have never tried to prevent

ndiswrapper from using their code.  Both times ndiswrapper was prevented
OK, I'll keep it in mind in case such approach actually becomes

necessary.
--

Regards,

Pavel Roskin

--

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

--

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

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

--

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

--