It seems that the kernel module loader taints ndiswrapper module as
proprietary, but it is not - it is fully GPL: see
http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
more accurate, it should check if the driver being loaded is GPL or not, but
that is not done).
Thanks,
Giri
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hello,
Have got the same problem. I just add the following:
1) dmesg claims __create_workqueue and __destroy_workqueue are undefined
(kernel syms)
2) I've checked out System.map and they're of course present
3) no problem under 2.6.18.1
4) from ndiswrapper-1.15 to ndiswrapper-1.26
By the way, i would like so much if someone explain me why, since
2.6.18, on my Acer Laptop i had to add irqpoll to correctly boot (had
already to use acpi=noirq) and still have strange errors on DVD
detection at boot which strangely has not any consequence later.
The problem is there since 2.6.18.
Thanks,
Gianluca
Giridhar Pemmasani wrote:
>It seems that the kernel module loader taints ndiswrapper module as
>proprietary, but it is not - it is fully GPL: see
>http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
>
>Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
>more accurate, it should check if the driver being loaded is GPL or not, but
>that is not done).
>
>Thanks,
>Giri
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
On Monday 23 October 2006 00:40, Giridhar Pemmasani wrote:
> It seems that the kernel module loader taints ndiswrapper module as
> proprietary, but it is not - it is fully GPL: see
> http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
Indeed. 'ndiswrapper' is intentionally tainted by kernel/module.c because it
is used to load and run unknown binary / proprietary code in kernel-space. If
this unknown binary / proprietary code were to contain a bug (which all code
of that complexity tends to), it might write to memory it doesn't own, or
coerce a device to do so on its behalf, making a kernel crash dump analysis
into a wild goose chase (hence the reason for kernel taint).
> Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
> more accurate, it should check if the driver being loaded is GPL or not,
> but that is not done).
Are you saying ndiswrapper voluntarily calls add_taint() whenever it loads an
NDIS driver?
Are there even any examples of GPL-licensed NDIS drivers?
> Thanks,
> Giri
>
Thanks,
Chase
--- Chase Venters <[email protected]> wrote:
> On Monday 23 October 2006 00:40, Giridhar Pemmasani wrote:
> > It seems that the kernel module loader taints ndiswrapper module as
> > proprietary, but it is not - it is fully GPL: see
> > http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
>
> Indeed. 'ndiswrapper' is intentionally tainted by kernel/module.c because
> it
> is used to load and run unknown binary / proprietary code in kernel-space.
> If
> this unknown binary / proprietary code were to contain a bug (which all
> code
> of that complexity tends to), it might write to memory it doesn't own, or
> coerce a device to do so on its behalf, making a kernel crash dump analysis
>
> into a wild goose chase (hence the reason for kernel taint).
Yes, I agree on the purpose of tainting the kernel.
> > Note that when a driver is loaded, ndiswrapper does taint the kernel (to
> be
> > more accurate, it should check if the driver being loaded is GPL or not,
> > but that is not done).
>
> Are you saying ndiswrapper voluntarily calls add_taint() whenever it loads
> an
> NDIS driver?
Exactly - the loader within ndiswrapper taints kernel versions 2.6.10 and
newer (older kernels don't have a way of tainting the kernel). The code is in
loader.c in ndiswrapper.
> Are there even any examples of GPL-licensed NDIS drivers?
I don't remember off hand, but sometime back there was discussion on related
topic of weather ndiswrapper should be in debian-main or not, and someone
pointed out a GPL ndis driver. (BTW, after much discussion on debian devel
list, the developers agreed that ndiswrapper belongs in debian-main.)
Giri
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Hi again,
tainting apart, do you get to load ndiswrapper ? On what kernel exactly ?
I cant on rc2-mm2
Thanks
Gianluca
Giridhar Pemmasani wrote:
>--- Chase Venters <[email protected]> wrote:
>
>
>
>>On Monday 23 October 2006 00:40, Giridhar Pemmasani wrote:
>>
>>
>>>It seems that the kernel module loader taints ndiswrapper module as
>>>proprietary, but it is not - it is fully GPL: see
>>>http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
>>>
>>>
>>Indeed. 'ndiswrapper' is intentionally tainted by kernel/module.c because
>>it
>>is used to load and run unknown binary / proprietary code in kernel-space.
>>If
>>this unknown binary / proprietary code were to contain a bug (which all
>>code
>>of that complexity tends to), it might write to memory it doesn't own, or
>>coerce a device to do so on its behalf, making a kernel crash dump analysis
>>
>>into a wild goose chase (hence the reason for kernel taint).
>>
>>
>
>Yes, I agree on the purpose of tainting the kernel.
>
>
>
>>>Note that when a driver is loaded, ndiswrapper does taint the kernel (to
>>>
>>>
>>be
>>
>>
>>>more accurate, it should check if the driver being loaded is GPL or not,
>>>but that is not done).
>>>
>>>
>>Are you saying ndiswrapper voluntarily calls add_taint() whenever it loads
>>an
>>NDIS driver?
>>
>>
>
>Exactly - the loader within ndiswrapper taints kernel versions 2.6.10 and
>newer (older kernels don't have a way of tainting the kernel). The code is in
>loader.c in ndiswrapper.
>
>
>
>>Are there even any examples of GPL-licensed NDIS drivers?
>>
>>
>
>I don't remember off hand, but sometime back there was discussion on related
>topic of weather ndiswrapper should be in debian-main or not, and someone
>pointed out a GPL ndis driver. (BTW, after much discussion on debian devel
>list, the developers agreed that ndiswrapper belongs in debian-main.)
>
>Giri
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
On Monday 23 October 2006 01:40, Giridhar Pemmasani wrote:
> Exactly - the loader within ndiswrapper taints kernel versions 2.6.10 and
> newer (older kernels don't have a way of tainting the kernel). The code is
> in loader.c in ndiswrapper.
Next question - what version of ndiswrapper started voluntary tainting (or has
it always?)
That is to say, are there versions of ndiswrapper floating around out there in
the ether capable of building against 2.6.19-rc* that don't voluntarily
add_taint()? (I'm guessing the answer is 'no', but the answer is possibly
important to consider)
The attached patch (untested) should keep the kernel from self-tainting when
ndiswrapper is inserted. The last question, then, is how everyone else feels
about this. Objections to removing the mandatory ndiswrapper taint?
Signed-off-by: Chase Venters <[email protected]>
diff --git a/kernel/module.c b/kernel/module.c
index 67009bd..f948a2c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1717,8 +1717,6 @@ #endif
/* Set up license info based on the info section */
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
- if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
On Sun, 2006-10-22 at 22:41 -0700, Giridhar Pemmasani wrote:
> It seems that the kernel module loader taints ndiswrapper module as
> proprietary, but it is not - it is fully GPL: see
> http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
>
> Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
> more accurate, it should check if the driver being loaded is GPL or not, but
> that is not done).
There is no reason (apart from "it hasn't been done yet2 which is a very
weak reason) to use ndiswrapper with a GPL-module - just port the
GPL-module over.
Bernd
--
Firmix Software GmbH http://www.firmix.at/
mobil: +43 664 4416156 fax: +43 1 7890849-55
Embedded Linux Development and Services
Hi,
if that can help, the problem with the undefined syms in ndiswrapper is
that the module was tainted, and couldnt get EXPORT_SYMBOL_GPL'd
__create_workqueue...
I applied Chase patch...everything goes.
In my opinion i would avoid tainting ndiswrapper.
Gianluca
Giridhar Pemmasani wrote:
>--- Chase Venters <[email protected]> wrote:
>
>
>
>>On Monday 23 October 2006 00:40, Giridhar Pemmasani wrote:
>>
>>
>>>It seems that the kernel module loader taints ndiswrapper module as
>>>proprietary, but it is not - it is fully GPL: see
>>>http://directory.fsf.org/sysadmin/hookup/ndiswrapper.html
>>>
>>>
>>Indeed. 'ndiswrapper' is intentionally tainted by kernel/module.c because
>>it
>>is used to load and run unknown binary / proprietary code in kernel-space.
>>If
>>this unknown binary / proprietary code were to contain a bug (which all
>>code
>>of that complexity tends to), it might write to memory it doesn't own, or
>>coerce a device to do so on its behalf, making a kernel crash dump analysis
>>
>>into a wild goose chase (hence the reason for kernel taint).
>>
>>
>
>Yes, I agree on the purpose of tainting the kernel.
>
>
>
>>>Note that when a driver is loaded, ndiswrapper does taint the kernel (to
>>>
>>>
>>be
>>
>>
>>>more accurate, it should check if the driver being loaded is GPL or not,
>>>but that is not done).
>>>
>>>
>>Are you saying ndiswrapper voluntarily calls add_taint() whenever it loads
>>an
>>NDIS driver?
>>
>>
>
>Exactly - the loader within ndiswrapper taints kernel versions 2.6.10 and
>newer (older kernels don't have a way of tainting the kernel). The code is in
>loader.c in ndiswrapper.
>
>
>
>>Are there even any examples of GPL-licensed NDIS drivers?
>>
>>
>
>I don't remember off hand, but sometime back there was discussion on related
>topic of weather ndiswrapper should be in debian-main or not, and someone
>pointed out a GPL ndis driver. (BTW, after much discussion on debian devel
>list, the developers agreed that ndiswrapper belongs in debian-main.)
>
>Giri
>
>__________________________________________________
>Do You Yahoo!?
>Tired of spam? Yahoo! Mail has the best spam protection around
>http://mail.yahoo.com
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
Giridhar Pemmasani wrote:
> --- Chase Venters <[email protected]> wrote:
>> Are there even any examples of GPL-licensed NDIS drivers?
>
> I don't remember off hand, but sometime back there was discussion on related
> topic of weather ndiswrapper should be in debian-main or not, and someone
> pointed out a GPL ndis driver. (BTW, after much discussion on debian devel
> list, the developers agreed that ndiswrapper belongs in debian-main.)
AFAIK, the only given example of a free NDIS driver was CIPE-Win32,
which is a port of CIPE from Linux to Windows. It's quite pointless to
use ndiswrapper for that.
Michal
Ar Sul, 2006-10-22 am 22:41 -0700, ysgrifennodd Giridhar Pemmasani:
> Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
> more accurate, it should check if the driver being loaded is GPL or not, but
> that is not done).
However by then it has already dynamically linked with explicit GPLONLY
symbols so it cannot then load a binary windows driver but should unload
itself or refuse to load anything but the GPL ndis drivers (of which
afaik only one exists), and even then they expect an environment
incompatible with the Linux kernel.
--- Chase Venters <[email protected]> wrote:
> Next question - what version of ndiswrapper started voluntary tainting (or
> has
> it always?)
>
> That is to say, are there versions of ndiswrapper floating around out there
> in
> the ether capable of building against 2.6.19-rc* that don't voluntarily
> add_taint()? (I'm guessing the answer is 'no', but the answer is possibly
> important to consider)
Since version 1.0, ndiswrapper has been tainting kernel when a driver is
loaded. Version 1.0 is quite old (circa Jan 2005) and won't build with any
recent kernels.
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
--- Alan Cox <[email protected]> wrote:
> However by then it has already dynamically linked with explicit GPLONLY
> symbols so it cannot then load a binary windows driver but should unload
> itself or refuse to load anything but the GPL ndis drivers (of which
> afaik only one exists), and even then they expect an environment
> incompatible with the Linux kernel.
So the idea of tainting is to _prevent_ any binary code being loaded into
kernel, even if kernel is marked as having binary code loaded, which I
thought was the purpose of tainting (so that people not interested in dealing
with binary code know they don't have/want to)? If that is the goal, how do
you know this scheme of adding names to module loader in kernel guarantees
that (now or in future)?
Thanks,
Giri
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
Ar Llu, 2006-10-23 am 04:35 -0700, ysgrifennodd Giridhar Pemmasani:
> So the idea of tainting is to _prevent_ any binary code being loaded into
> kernel, even if kernel is marked as having binary code loaded, which I
> thought was the purpose of tainting (so that people not interested in dealing
> with binary code know they don't have/want to)? If that is the goal, how do
> you know this scheme of adding names to module loader in kernel guarantees
> that (now or in future)?
There are two overlapping mechanisms here
Taint is used to identify situations where debug data may not be good,
that may be proprietary or other dubiously legal code, it may be forcing
SMP active on non SMP suitable systems, it may be overriding certain
options in a potentially hazardous fashion. Taint exists primarily to
help debugging data analysis.
EXPORT_SYMBOL_GPL() is used to assert that the symbol is absolutely
definitely not a public symbol. EXPORT_SYMBOL exports symbols which
might be but even then the GPL derivative work rules apply. When you
mark a driver GPL it is permitted to use _GPL symbols, but if it does so
it cannot then go and load other non GPL symbols and expect people not
to question its validity.
On Mon, 2006-10-23 at 11:41 +0100, Alan Cox wrote:
> Ar Sul, 2006-10-22 am 22:41 -0700, ysgrifennodd Giridhar Pemmasani:
> > Note that when a driver is loaded, ndiswrapper does taint the kernel (to be
> > more accurate, it should check if the driver being loaded is GPL or not, but
> > that is not done).
>
> However by then it has already dynamically linked with explicit GPLONLY
> symbols so it cannot then load a binary windows driver but should unload
> itself or refuse to load anything but the GPL ndis drivers (of which
> afaik only one exists), and even then they expect an environment
> incompatible with the Linux kernel.
The kernel itself links GPL code to non-GPL via the Posix API (the
syscall layer). The kernel also links GPL code to non-GPL via the PCI
layer (all that proprietary firmware on the other side). The
ndiswrapper links GPL code to non-GPL via the NDIS API.
No difference, really. Implementing a well-defined interface
abstraction layer doesn't make either side of it derived from the other.
(Exactly how well-defined, how abstract, and how derived are all
arguments for the lawyers.)
--
Zan Lynx <[email protected]>
--- Alan Cox <[email protected]> wrote:
> Taint is used to identify situations where debug data may not be good,
> that may be proprietary or other dubiously legal code, it may be forcing
> SMP active on non SMP suitable systems, it may be overriding certain
> options in a potentially hazardous fashion. Taint exists primarily to
> help debugging data analysis.
I have read the history of the patch that marked ndiswrapper as "proprietary
module", which is not correct (and that was the point of my original post).
All the posts realted to this referred to issues with loading binary code
into kernel (and since ndiswrapper does taint the kernel when a driver is
loaded, this again is misplaced).
> EXPORT_SYMBOL_GPL() is used to assert that the symbol is absolutely
> definitely not a public symbol. EXPORT_SYMBOL exports symbols which
> might be but even then the GPL derivative work rules apply. When you
> mark a driver GPL it is permitted to use _GPL symbols, but if it does so
> it cannot then go and load other non GPL symbols and expect people not
> to question its validity.
I was not fully aware of this issue until now (I have read posts related to
this issue now). Does this mean that any module that loads binary code can't
be GPL, even those that load firmware files? How is
non-GPL-due-to-transitivity going to be checked? Why does module loader mark
only couple of modules as non-GPL, when there are other drivers that load
some sort of binary code? It is understandable to mark a module as non-GPL if
it is lying about its license, but as far as that is concerned, ndiswrapper
(alone) is GPL.
Thanks,
Giri
__________________________________________________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
On Mon, 23 Oct 2006 19:43:47 -0700 (PDT) Giridhar Pemmasani wrote:
> --- Alan Cox <[email protected]> wrote:
>
> > Taint is used to identify situations where debug data may not be good,
> > that may be proprietary or other dubiously legal code, it may be forcing
> > SMP active on non SMP suitable systems, it may be overriding certain
> > options in a potentially hazardous fashion. Taint exists primarily to
> > help debugging data analysis.
>
> I have read the history of the patch that marked ndiswrapper as "proprietary
> module", which is not correct (and that was the point of my original post).
> All the posts realted to this referred to issues with loading binary code
> into kernel (and since ndiswrapper does taint the kernel when a driver is
> loaded, this again is misplaced).
The kernel should not depend on a not-in-tree kernel module to
taint the kernel. The kernel can and should do that itself.
(big) If ndiswrapper were ever added to the kernel tree, then that would
be a reasonable place to do/add the tainting.
> > EXPORT_SYMBOL_GPL() is used to assert that the symbol is absolutely
> > definitely not a public symbol. EXPORT_SYMBOL exports symbols which
> > might be but even then the GPL derivative work rules apply. When you
> > mark a driver GPL it is permitted to use _GPL symbols, but if it does so
> > it cannot then go and load other non GPL symbols and expect people not
> > to question its validity.
>
> I was not fully aware of this issue until now (I have read posts related to
> this issue now). Does this mean that any module that loads binary code can't
> be GPL, even those that load firmware files? How is
> non-GPL-due-to-transitivity going to be checked? Why does module loader mark
> only couple of modules as non-GPL, when there are other drivers that load
> some sort of binary code? It is understandable to mark a module as non-GPL if
> it is lying about its license, but as far as that is concerned, ndiswrapper
> (alone) is GPL.
---
~Randy
>
>The kernel itself links GPL code to non-GPL via the Posix API (the
>syscall layer). The kernel also links GPL code to non-GPL via the PCI
>layer (all that proprietary firmware on the other side). The
>ndiswrapper links GPL code to non-GPL via the NDIS API.
>
>No difference, really.
Behind the syscall layer is userspace (the well known ring 3), which, all bugs
and problems aside, and exceptions like ioperm ruled out, cannot crash the
kernel.
I am not too aware about firmware and how it affects the running kernel, but
usually it is a binary blob that gets loaded into the PCI device. May or may
not crash the kernel - as said, I am not too aware of how it can tamper with
the kernel.
NDIS code however is, unlike the above, run unconditionally in superprivileged
level (ring 0), which quite distinct from userspace or firmwarespace[note
warning above].
Lastly, there is the new IIO code, which sounds like it is a well-defined (you
name it) interface, to userspace however.
If Windows drivers could run in userspace, there would not be a problem, would
there be?
> Implementing a well-defined interface
>abstraction layer doesn't make either side of it derived from the other.
>(Exactly how well-defined, how abstract, and how derived are all
>arguments for the lawyers.)
>--
>Zan Lynx <[email protected]>
>
-`J'
--
On 10/24/06, Randy Dunlap <[email protected]> wrote:
> The kernel should not depend on a not-in-tree kernel module to
> taint the kernel. The kernel can and should do that itself.
Agreed. But should the kernel disallow the use of _GPL symbols for
ndiswrapper? I would say no.
Ar Maw, 2006-10-24 am 15:12 +0300, ysgrifennodd Pekka Enberg:
> On 10/24/06, Randy Dunlap <[email protected]> wrote:
> > The kernel should not depend on a not-in-tree kernel module to
> > taint the kernel. The kernel can and should do that itself.
>
> Agreed. But should the kernel disallow the use of _GPL symbols for
> ndiswrapper? I would say no.
I'd agree providing the attempt to taint function allows an error return
if it did so and it then refuses to load non-GPL windows drivers.
Ar Llu, 2006-10-23 am 19:43 -0700, ysgrifennodd Giridhar Pemmasani:
> I was not fully aware of this issue until now (I have read posts related to
> this issue now). Does this mean that any module that loads binary code can't
> be GPL, even those that load firmware files? How is
Firmware is usually more clearly separated (the problem ultimately is
that "derived work" is a legal not a technical distinction).
> non-GPL-due-to-transitivity going to be checked? Why does module loader mark
> only couple of modules as non-GPL, when there are other drivers that load
> some sort of binary code? It is understandable to mark a module as non-GPL if
> it is lying about its license, but as far as that is concerned, ndiswrapper
> (alone) is GPL.
Yes. I don't think the current situation is neccessarily correct, but if
it uses EXPORT_SYMBOL_GPL then the "now taint me" ought to fail and the
driver ought to refuse to load a non GPL windows driver.
Alan
Hello, Alan!
>
> > non-GPL-due-to-transitivity going to be checked? Why does module loader mark
> > only couple of modules as non-GPL, when there are other drivers that load
> > some sort of binary code? It is understandable to mark a module as non-GPL if
> > it is lying about its license, but as far as that is concerned, ndiswrapper
> > (alone) is GPL.
>
> Yes. I don't think the current situation is neccessarily correct, but if
> it uses EXPORT_SYMBOL_GPL then the "now taint me" ought to fail and the
> driver ought to refuse to load a non GPL windows driver.
Why is that? I don't see any reasonable argument behind this
requirement. "now taint me" is not an equivalent to "I was lying about
my license". It means "I'm going to to something that kernel developers
don't want to debug".
I don't see any legal reasons behind this restriction. A driver under
GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
technical mechanism of enforcing GPL against non-free code, but
ndiswrapper is free. The non-free NDIS drivers are not using those
symbols.
Neither do I see any technical reasons. Tainting already means that the
kernel developers are not interested in possible problems created by the
driver. Imposing further limits on functionality of ndiswrapper makes
no sense. It only creates problems.
How is this situation different from denying other capabilities to the
drivers that have used GPL symbols? How can I be sure that my driver
will be able to request firmware from userspace even though it uses
sysfs functionality via EXPORT_SYMBOL_GPL? What if somebody decides
that it's immoral or questionable for a GPL driver to do so?
Regardless of whether ndiswrapper can work around the limitations
imposed on it, it sets a very bad precedent when kernel developers are
arbitrarily and deliberately breaking existing functionality of an
external driver without having any excuse whatsoever.
I hope the offending code will be backed from the kernel for 2.6.19. In
my opinion, further changes in that direction (if they are needed)
should be based on more solid reasons.
--
Regards,
Pavel Roskin
Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> I don't see any legal reasons behind this restriction. A driver under
> GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
> technical mechanism of enforcing GPL against non-free code, but
> ndiswrapper is free. The non-free NDIS drivers are not using those
> symbols.
The combination of GPL wrapper and the NDIS driver as a work is not free
(in fact its questionable if its even legal to ship such a combination
together).
On Oct 25, 2006, at 16:30:26, Alan Cox wrote:
> Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
>> I don't see any legal reasons behind this restriction. A driver
>> under GPL should be able to use any exported symbols.
>> EXPORT_SYMBOL_GPL is a technical mechanism of enforcing GPL
>> against non-free code, but ndiswrapper is free. The non-free NDIS
>> drivers are not using those symbols.
>
> The combination of GPL wrapper and the NDIS driver as a work is not
> free (in fact its questionable if its even legal to ship such a
> combination together).
Assume the existence of two programs, Foo and Bar (ndiswrapper and
vendor-NDIS-driver). If Foo and Bar are different licenses (GPL vs
proprietary) it is not legal to distribute them as part of a single
work unless you convince the copyright owners to relicense. It _is_
however, perfectly legal for an end user to download Foo from
http://www.foo.com and Bar from http://www.bar.com and combine the two on his
computer, whether or not that does anything useful. Since the
ndiswrapper driver was not based on any particular driver but on a
defined standard, using ndiswrapper with a proprietary NDIS driver is
just as legal as using a proprietary database server on a GPLed Linux
system. The technical issues of which ring the code runs in is
irrelevant as long as the user obtained both pieces separately and
neither is a derivative work of the other.
Besides, if the user does not distribute it then copyright law is
irrelevant.
Cheers,
Kyle Moffett
Ar Mer, 2006-10-25 am 16:40 -0400, ysgrifennodd Kyle Moffett:
> Besides, if the user does not distribute it then copyright law is
> irrelevant.
>
That would be sane but in most jurisdictions loading into memory to
execute is "copying".
On Wed, 2006-10-25 at 21:30 +0100, Alan Cox wrote:
> Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> > I don't see any legal reasons behind this restriction. A driver under
> > GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
> > technical mechanism of enforcing GPL against non-free code, but
> > ndiswrapper is free. The non-free NDIS drivers are not using those
> > symbols.
>
> The combination of GPL wrapper and the NDIS driver as a work is not free
> (in fact its questionable if its even legal to ship such a combination
> together).
So, the problem is on the legal side.
But I have to ask - which NDIS driver? I can write a free NDIS driver
and use it with ndiswrapper. You can say it's a stupid thing to do, but
once you talk about the legality, the only argument should be
legal/illegal. Besides, it may be a not such a bad idea for a ReactOS
developer writing a ReactOS driver to test it with Linux.
Also, nothing should prevent me from combining ndiswrapper with any
Windows driver in the privacy of my home as long as I don't distribute
anything. GPL doesn't have use restrictions (although the driver may
have an EULA).
Since the problem is with USB symbols, I can split the USB part from
ndiswrapper and call it ndiswrapper-usb. Then ndiswrapper-usb will be
calling the GPL-only symbols while ndiswrapper will be loading the
non-free modules. Good luck catching that! It's actually a change that
makes sense technically. Imagine what a change specifically intended to
fool Linux would do!
I don't see how the kernel can detect the cases where GPL is actually
violated without creating problem for honest users. Kernel code is not
a police department, let alone a court of law. Let's not create out own
DRM right in the kernel!
Companies that ship ndiswrapper with non-free modules may be breaking
copyright laws already. But it's not something that should be fought by
kernel patches.
--
Regards,
Pavel Roskin
On Wed, Oct 25, 2006 at 05:06:32PM -0400, Pavel Roskin wrote:
> On Wed, 2006-10-25 at 21:30 +0100, Alan Cox wrote:
> > Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> > > I don't see any legal reasons behind this restriction. A driver under
> > > GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
> > > technical mechanism of enforcing GPL against non-free code, but
> > > ndiswrapper is free. The non-free NDIS drivers are not using those
> > > symbols.
> >
> > The combination of GPL wrapper and the NDIS driver as a work is not free
> > (in fact its questionable if its even legal to ship such a combination
> > together).
>
> So, the problem is on the legal side.
>
> But I have to ask - which NDIS driver? I can write a free NDIS driver
> and use it with ndiswrapper. You can say it's a stupid thing to do, but
> once you talk about the legality, the only argument should be
> legal/illegal. Besides, it may be a not such a bad idea for a ReactOS
> developer writing a ReactOS driver to test it with Linux.
>
> Also, nothing should prevent me from combining ndiswrapper with any
> Windows driver in the privacy of my home as long as I don't distribute
> anything. GPL doesn't have use restrictions (although the driver may
> have an EULA).
>
> Since the problem is with USB symbols, I can split the USB part from
> ndiswrapper and call it ndiswrapper-usb. Then ndiswrapper-usb will be
> calling the GPL-only symbols while ndiswrapper will be loading the
> non-free modules. Good luck catching that! It's actually a change that
> makes sense technically. Imagine what a change specifically intended to
> fool Linux would do!
>
> I don't see how the kernel can detect the cases where GPL is actually
> violated without creating problem for honest users. Kernel code is not
> a police department, let alone a court of law. Let's not create out own
> DRM right in the kernel!
>
> Companies that ship ndiswrapper with non-free modules may be breaking
> copyright laws already. But it's not something that should be fought by
> kernel patches.
No matter how the legal situation looks like: do we *want* to support
drivers that use an API totally alien to Linux concepts?
Personally I feel that no matter if they are legal or not, we should not
cater to such drivers in the first place. If it's trickier to use
Windows API-drivers under Linux than to write a native Linux driver,
big deal... We don't want Windows-drivers. We want native drivers.
Regards: David Weinehall
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
On Wed, 2006-10-25 at 23:33 +0200, David Weinehall wrote:
> No matter how the legal situation looks like: do we *want* to support
> drivers that use an API totally alien to Linux concepts?
The word "support" is overloaded. I think tainting was striking the
perfect balance between the two meanings. The driver would work, but
the kernel developers could ignore problems with the driver.
What is going on now is making sure that the driver doesn't work. At
least that's my understanding of Alan's intention not to allow code
loading for modules that have used GPL-only symbols.
And that's what I think is way over the top. It's akin looking for
process called "wine" (or detecting it by its behavior) and denying it
access to some syscalls.
> Personally I feel that no matter if they are legal or not, we should not
> cater to such drivers in the first place. If it's trickier to use
> Windows API-drivers under Linux than to write a native Linux driver,
> big deal... We don't want Windows-drivers. We want native drivers.
The only non-native part of ndiswrapper is NDIS, as opposed to bare
hardware access. ndiswrapper implements quite a lot of functionality in
the free code.
Discouraging the ndiswrapper developer is especially unfair because he
did much better job at supporting such features as WPA, compared to what
some of us, myself included, did with the free drivers.
I'm not against free and fully open drivers, but they won't appear
overnight. Sometimes ndiswrapper is a good starting point to understand
what the hardware can do and whether it's functional at all. It could
also be used for reverse engineering.
--
Regards,
Pavel Roskin
Ar Mer, 2006-10-25 am 18:02 -0400, ysgrifennodd Pavel Roskin:
> And that's what I think is way over the top. It's akin looking for
> process called "wine" (or detecting it by its behavior) and denying it
> access to some syscalls.
On the contrary there is little likelyhood that wine is a derivative
work, and even if it was the note with the kernel explicitly deals with
that by saying "we don't intend a judge to interpret it that way"
Ar Mer, 2006-10-25 am 23:33 +0200, ysgrifennodd David Weinehall:
> Personally I feel that no matter if they are legal or not, we should not
> cater to such drivers in the first place. If it's trickier to use
> Windows API-drivers under Linux than to write a native Linux driver,
> big deal... We don't want Windows-drivers. We want native drivers.
Neither taint nor _GPL are intended to stop people doing things that, in
the eyes of the masses, are stupid. The taint mark is there to ensure
that they don't harm the rest of us. The FSF view of freedom is freedom
to modify not freedom to modify in a manner approved by some defining
body.
Alan
On Wed, Oct 25, 2006 at 11:58:38PM +0100, Alan Cox wrote:
> Ar Mer, 2006-10-25 am 23:33 +0200, ysgrifennodd David Weinehall:
> > Personally I feel that no matter if they are legal or not, we should not
> > cater to such drivers in the first place. If it's trickier to use
> > Windows API-drivers under Linux than to write a native Linux driver,
> > big deal... We don't want Windows-drivers. We want native drivers.
>
> Neither taint nor _GPL are intended to stop people doing things that, in
> the eyes of the masses, are stupid. The taint mark is there to ensure
> that they don't harm the rest of us. The FSF view of freedom is freedom
> to modify not freedom to modify in a manner approved by some defining
> body.
Hence my use of the world "Personally". It's my own opinion that we
shouldn't support Windows API-drivers. I don't think this has anything
to do with the FSF view on freedom. This has to do with the freedom to
make a sound technical decision.
Regards: David
--
/) David Weinehall <[email protected]> /) Northern lights wander (\
// Maintainer of the v2.0 kernel // Dance across the winter sky //
\) http://www.acc.umu.se/~tao/ (/ Full colour fire (/
> On Wed, 25 Oct 2006 21:30:26 +0100 Alan Cox <[email protected]> wrote:
> Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> > I don't see any legal reasons behind this restriction. A driver under
> > GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
> > technical mechanism of enforcing GPL against non-free code, but
> > ndiswrapper is free. The non-free NDIS drivers are not using those
> > symbols.
>
> The combination of GPL wrapper and the NDIS driver as a work is not free
> (in fact its questionable if its even legal to ship such a combination
> together).
May be so. But this patch was supposed to print a helpful taint message to
draw our attention to the fact that ndis-wrapper was in use. The patch was
not intended to cause gpl'ed modules to stop loading (or if is was, that
effect was concealed from yours truly).
IOW, this was a mistake.
Now, if we do want to disallow gpl module loading after ndis-wrapper has
been used then fine, we can discuss that. If we decide to proceed that way
then we will probably cause a load of ndis-wrapper to emit a scary printk for
six months or so to give people time to make arrangements.
Hello,
i apologize for being bothering you twice in three days but i was
wondering whether someone has found reason why ndiswrapper does not load
on 2.6.19-rc2-mm2.
NOTE: it seems to be related to tainting
I try to resume a bit:
__create_workqueue undefined symbol
queue_work undefined symbol
After patching modules.c to remove tainting of ndiswrapper i got to load
it without problems but it doesnt seem a modules.c problem (those
symbols are EXPORT_GPL since at least 2.6.18), modules.c and workqueue.c
are as of 2.6.16 kernel.
Is there any new ?
If i can tell my user opinion about tainting is that it s...cks in
general, dont know any case in which it fits something, i mean in life
not just linux kernel.
One who uses ndiswrapper doest it at his own risk, a developer or
debugger can manage...
And the blacklist hardcoded in modules.c, as someone used to say couple
days ago, seems really hard to carry on !
THanks to anyone who will find time to show me the light,
Gianluca
Ar Mer, 2006-10-25 am 20:59 -0700, ysgrifennodd Andrew Morton:
> May be so. But this patch was supposed to print a helpful taint message to
> draw our attention to the fact that ndis-wrapper was in use. The patch was
> not intended to cause gpl'ed modules to stop loading
The stopping loading is purely because it now uses _GPLONLY symbols,
which is fine until the user wants to load a windows driver except for
the old CIPE driver. Some assumptions broke somewhere along the way and
the chain of events that was never forseen unfolded.
> Now, if we do want to disallow gpl module loading after ndis-wrapper has
> been used then fine
The problem is we do the dynamic link at module load time. We would have
to unlink the module if it tried to taint itself, which is clearly not
what the end user needs to suffer. Having the taint function actually
taint and printk + return a "Linked gplonly you can't" error seems the
better solution.
Really ndiswrapper shouldn't be using _GPLONLY symbols, that would
actually make it useful to the binary driver afflicted again and more
likely to be legal.
Alan Cox wrote:
> The stopping loading is purely because it now uses _GPLONLY symbols,
> which is fine until the user wants to load a windows driver except for
> the old CIPE driver. Some assumptions broke somewhere along the way and
> the chain of events that was never forseen unfolded.
>
>> Now, if we do want to disallow gpl module loading after ndis-wrapper has
>> been used then fine
>
> The problem is we do the dynamic link at module load time. We would have
> to unlink the module if it tried to taint itself, which is clearly not
> what the end user needs to suffer. Having the taint function actually
> taint and printk + return a "Linked gplonly you can't" error seems the
> better solution.
>
> Really ndiswrapper shouldn't be using _GPLONLY symbols, that would
> actually make it useful to the binary driver afflicted again and more
> likely to be legal.
I'm confused on the discussion:
legal? I don't find how a windo$e driver can be "derived work" of Linux,
and anyway they use a "standard" interface. So it is acceptable for GPL
(IMHO and IANAL). so it is not a legal problem.
I see only a development question:
should we allow untrusted module to know and modify the
"intimate" part of kernel, and cause compability and other large
amount of problems into kernel developers, distribution and users?
So it is a political question, not a legal question!
ciao
cate
Giacomo A. Catenazzi wrote:
> I'm confused on the discussion:
> legal? I don't find how a windo$e driver can be "derived work" of Linux,
> and anyway they use a "standard" interface. So it is acceptable for GPL
> (IMHO and IANAL). so it is not a legal problem.
>
> I see only a development question:
> should we allow untrusted module to know and modify the
> "intimate" part of kernel, and cause compability and other large
> amount of problems into kernel developers, distribution and users?
>
I really cannot see even a political problem. I the case of ndiswrapper
the problem is not whether we want to support windows or whatever
drivermodules, but if we want to support NDIS drivers with a GPL wrapper.
regards,
Gianluca
> So it is a political question, not a legal question!
>
> ciao
> cate
> -
> To unsubscribe from this list: send the line "unsubscribe
> linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
David Weinehall <[email protected]> writes:
> > > Personally I feel that no matter if they are legal or not, we
> > > should not cater to such drivers in the first place. If it's
> > > trickier to use Windows API-drivers under Linux than to write a
> > > native Linux driver, big deal... We don't want Windows-drivers.
> > > We want native drivers.
> >
> > Neither taint nor _GPL are intended to stop people doing things
> > that, in the eyes of the masses, are stupid. The taint mark is
> > there to ensure that they don't harm the rest of us. The FSF view
> > of freedom is freedom to modify not freedom to modify in a manner
> > approved by some defining body.
>
> Hence my use of the world "Personally". It's my own opinion that we
> shouldn't support Windows API-drivers. I don't think this has
> anything to do with the FSF view on freedom. This has to do with
> the freedom to make a sound technical decision.
and your freedom to do whatever you want at home isn't restricted by
the tainting.
Thierry Vignaud wrote:
>David Weinehall <[email protected]> writes:
>
>
>
>>>>Personally I feel that no matter if they are legal or not, we
>>>>should not cater to such drivers in the first place. If it's
>>>>trickier to use Windows API-drivers under Linux than to write a
>>>>native Linux driver, big deal... We don't want Windows-drivers.
>>>>We want native drivers.
>>>>
>>>>
>>>Neither taint nor _GPL are intended to stop people doing things
>>>that, in the eyes of the masses, are stupid. The taint mark is
>>>there to ensure that they don't harm the rest of us. The FSF view
>>>of freedom is freedom to modify not freedom to modify in a manner
>>>approved by some defining body.
>>>
>>>
>>Hence my use of the world "Personally". It's my own opinion that we
>>shouldn't support Windows API-drivers. I don't think this has
>>anything to do with the FSF view on freedom. This has to do with
>>the freedom to make a sound technical decision.
>>
>>
>
>and your freedom to do whatever you want at home isn't restricted by
>the tainting.
>
>
In fact it is now, because ndiswrapper doesnt load on 2.6.19.
The fact: there's a lot of people who are not gonna be using his wlan
unless they are able to modify the sources.
I wouldnt forget that ndiswrapper is a tool which solves problems. Linux
diffusion is affected by compatibility issues.
I really cant see the benefit for Linux in stop supporting windows NDIS
drivers...there's a lot of hardware which works only by that.
>-
>To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
>the body of a message to [email protected]
>More majordomo info at http://vger.kernel.org/majordomo-info.html
>Please read the FAQ at http://www.tux.org/lkml/
>
>
On Thu, Oct 26, 2006 at 11:39:59AM +0100, Alan Cox wrote:
> Ar Mer, 2006-10-25 am 20:59 -0700, ysgrifennodd Andrew Morton:
> > May be so. But this patch was supposed to print a helpful taint message to
> > draw our attention to the fact that ndis-wrapper was in use. The patch was
> > not intended to cause gpl'ed modules to stop loading
>
> The stopping loading is purely because it now uses _GPLONLY symbols,
> which is fine until the user wants to load a windows driver except for
> the old CIPE driver. Some assumptions broke somewhere along the way and
> the chain of events that was never forseen unfolded.
Could we please decide WTF _GPLONLY *is* and at least remain consistent?
Aside of "method of fighting binary-only modules", that is - this part
is obvious.
I'm not fond of ndiswrapper and stuff it uses, but AFAICS the list of
symbols it uses doesn't look like poking in the guts of kernel.
ISTR explanations along the lines of "well, it's for the stuff that
shouldn't be used by out-of-tree code". Does anybody still subscribe
to that or should that be considered a pure smokescreen?
Ar Iau, 2006-10-26 am 15:41 +0100, ysgrifennodd Al Viro:
> Could we please decide WTF _GPLONLY *is* and at least remain consistent?
> Aside of "method of fighting binary-only modules", that is - this part
> is obvious.
It was originally added to mark symbols that are clearly internal only
and make a work derivative. It's somewhere expanded to include symbols
whose code authors think that a cease and desist is the correct answer
to non GPL use.
I can't really help personally on the details there since I'm of the
opinion that _GPLONLY while useful doesn't generally make a blind bit of
difference as most if not all binary modules are violating the license.
(And I'm sure Nvidia's legal counsel disagrees with me at least in
public)
Alan
On Thu, 26 Oct 2006 11:39:59 +0100
Alan Cox <[email protected]> wrote:
> Ar Mer, 2006-10-25 am 20:59 -0700, ysgrifennodd Andrew Morton:
> > May be so. But this patch was supposed to print a helpful taint message to
> > draw our attention to the fact that ndis-wrapper was in use. The patch was
> > not intended to cause gpl'ed modules to stop loading
>
> The stopping loading is purely because it now uses _GPLONLY symbols,
> which is fine until the user wants to load a windows driver except for
> the old CIPE driver. Some assumptions broke somewhere along the way and
> the chain of events that was never forseen unfolded.
>
> > Now, if we do want to disallow gpl module loading after ndis-wrapper has
> > been used then fine
>
> The problem is we do the dynamic link at module load time. We would have
> to unlink the module if it tried to taint itself, which is clearly not
> what the end user needs to suffer. Having the taint function actually
> taint and printk + return a "Linked gplonly you can't" error seems the
> better solution.
>
> Really ndiswrapper shouldn't be using _GPLONLY symbols, that would
> actually make it useful to the binary driver afflicted again and more
> likely to be legal.
>
What are the symbols in question? A simple test would be to take the GPL
MODULE_LICENSE() off of ndiswrapper and try loading it.
--
Stephen Hemminger <[email protected]>
Stephen Hemminger wrote:
>On Thu, 26 Oct 2006 11:39:59 +0100
>Alan Cox <[email protected]> wrote:
>
>
>
>>Ar Mer, 2006-10-25 am 20:59 -0700, ysgrifennodd Andrew Morton:
>>
>>
>>>May be so. But this patch was supposed to print a helpful taint message to
>>>draw our attention to the fact that ndis-wrapper was in use. The patch was
>>>not intended to cause gpl'ed modules to stop loading
>>>
>>>
>>The stopping loading is purely because it now uses _GPLONLY symbols,
>>which is fine until the user wants to load a windows driver except for
>>the old CIPE driver. Some assumptions broke somewhere along the way and
>>the chain of events that was never forseen unfolded.
>>
>>
>>
>>>Now, if we do want to disallow gpl module loading after ndis-wrapper has
>>>been used then fine
>>>
>>>
>>The problem is we do the dynamic link at module load time. We would have
>>to unlink the module if it tried to taint itself, which is clearly not
>>what the end user needs to suffer. Having the taint function actually
>>taint and printk + return a "Linked gplonly you can't" error seems the
>>better solution.
>>
>>Really ndiswrapper shouldn't be using _GPLONLY symbols, that would
>>actually make it useful to the binary driver afflicted again and more
>>likely to be legal.
>>
>>
>>
>
>What are the symbols in question? A simple test would be to take the GPL
>MODULE_LICENSE() off of ndiswrapper and try loading it.
>
>
>
i've found:
__create_workqueue
queue_work
As i said removing add_taint() in modules.c in the section regarding
ndiswrapper makes the module load correctly.
regards,
Gianluca
On Wed, 25 Oct 2006 20:59:23 -0700 Andrew Morton wrote:
> > On Wed, 25 Oct 2006 21:30:26 +0100 Alan Cox <[email protected]> wrote:
> > Ar Mer, 2006-10-25 am 16:11 -0400, ysgrifennodd Pavel Roskin:
> > > I don't see any legal reasons behind this restriction. A driver under
> > > GPL should be able to use any exported symbols. EXPORT_SYMBOL_GPL is a
> > > technical mechanism of enforcing GPL against non-free code, but
> > > ndiswrapper is free. The non-free NDIS drivers are not using those
> > > symbols.
> >
> > The combination of GPL wrapper and the NDIS driver as a work is not free
> > (in fact its questionable if its even legal to ship such a combination
> > together).
>
> May be so. But this patch was supposed to print a helpful taint message to
> draw our attention to the fact that ndis-wrapper was in use. The patch was
> not intended to cause gpl'ed modules to stop loading (or if is was, that
> effect was concealed from yours truly).
>
> IOW, this was a mistake.
>
>
> Now, if we do want to disallow gpl module loading after ndis-wrapper has
> been used then fine, we can discuss that. If we decide to proceed that way
> then we will probably cause a load of ndis-wrapper to emit a scary printk for
> six months or so to give people time to make arrangements.
Yes, if I understand what's happening, then this was an unintended
consequence.
Does the patch below allow ndiswrapper to operate?
Of course, this still leaves the kernel marked as tainted,
without an indication of which module caused that. Not the best
situation.
---
From: Randy Dunlap <[email protected]>
For ndiswrapper and driverloader, don't set the module->taints
flags, just set the kernel global tainted flag.
This should allow ndiswrapper to continue to use GPL symbols.
Not tested.
Signed-off-by: Randy Dunlap <[email protected]>
---
kernel/module.c | 4 ++--
1 files changed, 2 insertions(+), 2 deletions(-)
--- linux-2619-rc3-pv.orig/kernel/module.c
+++ linux-2619-rc3-pv/kernel/module.c
@@ -1718,9 +1718,9 @@ static struct module *load_module(void _
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+ add_taint(TAINT_PROPRIETARY_MODULE);
if (strcmp(mod->name, "driverloader") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+ add_taint(TAINT_PROPRIETARY_MODULE);
/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);
On Thu, 2006-10-26 at 11:39 +0100, Alan Cox wrote:
> Really ndiswrapper shouldn't be using _GPLONLY symbols, that would
> actually make it useful to the binary driver afflicted again and more
> likely to be legal.
usb_register_driver is using EXPORT_SYMBOL_GPL_FUTURE, which means all
USB drivers will have to be GPL soon. This would disable the USB
support in ndiswrapper.
There is no other way to register USB drivers. Apparently, the USB
developers feel that every Linux USB driver should be considered a
derived work of Linux, and therefore should be under GPL.
This means that ndiswrapper would be considered as a derived work of
Linux. Since ndiswrapper is under GPL, it would suffer unfairly if the
meaning of EXPORT_SYMBOL_GPL is extended to restrict GPLed modules
capable of loading proprietary code into the kernel.
The second problem is sysfs. Again, using sysfs is only allowed to
GPLed modules for the same reason. Although ndiswrapper is not using
sysfs now, it would be unfair to restrict it from doing that in the
future.
It's not like the proprietary modules would be using Linux USB or sysfs
API - they are unaware of Linux. Only the free code can use it.
--
Regards,
Pavel Roskin
On Thu, Oct 26, 2006 at 03:19:00PM -0400, Pavel Roskin wrote:
>...
>
> This means that ndiswrapper would be considered as a derived work of
> Linux. Since ndiswrapper is under GPL, it would suffer unfairly if the
> meaning of EXPORT_SYMBOL_GPL is extended to restrict GPLed modules
> capable of loading proprietary code into the kernel.
>...
You could always write a tiny GPL-ed wrapper module with the sole
purpose of offering all EXPORT_SYMBOL_GPL'ed functions through
EXPORT_SYMBOL'ed wrapper functions.
You are using a gnu.org address for publically stating that trying to
prevent such kinds of wrapping was unfair?
It's not even clear that any modules containing non-GPL'ed code were
legal.
EXPORT_SYMBOL_GPL shows a pretty clear intention, and offering
functionality provided throug h EXPORT_SYMBOL_GPL'ed symbols to
proprietary code sounds very fishy.
> Regards,
> Pavel Roskin
cu
Adrian
--
"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 Thu, 2006-10-26 at 23:46 +0200, Adrian Bunk wrote:
> On Thu, Oct 26, 2006 at 03:19:00PM -0400, Pavel Roskin wrote:
> >...
> >
> > This means that ndiswrapper would be considered as a derived work of
> > Linux. Since ndiswrapper is under GPL, it would suffer unfairly if the
> > meaning of EXPORT_SYMBOL_GPL is extended to restrict GPLed modules
> > capable of loading proprietary code into the kernel.
> >...
>
> You could always write a tiny GPL-ed wrapper module with the sole
> purpose of offering all EXPORT_SYMBOL_GPL'ed functions through
> EXPORT_SYMBOL'ed wrapper functions.
Yes, but it's irrelevant. The kernel should not dictate how ndiswrapper
or any other driver should be structured.
I think such module would be quite inelegant. It would be a useless
layer of indirection created to compensate for a kernel bug.
> You are using a gnu.org address for publically stating that trying to
> prevent such kinds of wrapping was unfair?
I didn't even consider this trick. I was talking about a more
reasonable split of the code loader from the bus-specific code. Neither
did I suggest that it would be unfair to block any wrapping. I said it
would be hard and technically infeasible.
I'm using the same e-mail address for all free software work. I don't
represent Free Software Foundation, although I consider it a honor to
have an account with them.
> It's not even clear that any modules containing non-GPL'ed code were
> legal.
I'm not a lawyer, but I think one cannot classify software as legal or
illegal. The law governs what people do. Running such mix may be legal
even if distribution is not.
Anyway, I don't think it's relevant to ndiswrapper.
> EXPORT_SYMBOL_GPL shows a pretty clear intention, and offering
> functionality provided throug h EXPORT_SYMBOL_GPL'ed symbols to
> proprietary code sounds very fishy.
Last time I checked, EXPORT_SYMBOL_GPL was an indication that a code
using it will be considered as a work derived from Linux. This way,
ndiswrapper, which is free software, can be considered a derived work.
NDIS drivers don't know about any Linux API, therefore they cannot use
it directly. The purpose of ndiswrapper is not to remove limitations
from the Linux API, but to present a completely different API.
Non-free code does not contains any code derived from Linux because it
wasn't even written for Linux.
--
Regards,
Pavel Roskin
On Thu, Oct 26, 2006 at 06:29:53PM -0400, Pavel Roskin wrote:
> On Thu, 2006-10-26 at 23:46 +0200, Adrian Bunk wrote:
>...
> > It's not even clear that any modules containing non-GPL'ed code were
> > legal.
>
> I'm not a lawyer, but I think one cannot classify software as legal or
> illegal.
That's wrong, e.g. in some jurisdictions writing software that
circumvents copyright protections is forbidden by law.
> The law governs what people do. Running such mix may be legal
> even if distribution is not.
>
> Anyway, I don't think it's relevant to ndiswrapper.
>...
All non-GPL'ed modules are in a grey area, and the question isn't
whether it's black or white but how light or dark the grey is...
> Regards,
> Pavel Roskin
cu
Adrian
--
"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 Fri, 27 Oct 2006, Adrian Bunk wrote:
> On Thu, Oct 26, 2006 at 06:29:53PM -0400, Pavel Roskin wrote:
>> Anyway, I don't think it's relevant to ndiswrapper.
>> ...
>
> All non-GPL'ed modules are in a grey area, and the question isn't
> whether it's black or white but how light or dark the grey is...
ndiswrapper is GPL, but is (with the current code) not allowed to use the
gpl-only'ed symbols.
c'ya
sven
--
The Internet treats censorship as a routing problem, and routes around it.
(John Gilmore on http://www.cygnus.com/~gnu/)
On Fri, 2006-10-27 at 01:00 +0200, Adrian Bunk wrote:
> On Thu, Oct 26, 2006 at 06:29:53PM -0400, Pavel Roskin wrote:
> > On Thu, 2006-10-26 at 23:46 +0200, Adrian Bunk wrote:
> >...
> > > It's not even clear that any modules containing non-GPL'ed code were
> > > legal.
> >
> > I'm not a lawyer, but I think one cannot classify software as legal or
> > illegal.
>
> That's wrong, e.g. in some jurisdictions writing software that
> circumvents copyright protections is forbidden by law.
Fortunately, it would take a long flight of imagination to classify
ndiswrapper as "software that circumvents copyright protections". One
would have to claim that ndiswrapper is "bundling" itself with non-free
code and "distributing" that "bundle" from the hard drive into RAM, or
something just as ridiculous.
Anyway, I'm glad that the sanity has prevailed for now.
--
Regards,
Pavel Roskin
On Fri, Oct 27, 2006 at 01:36:41AM +0200, Sven-Haegar Koch wrote:
> On Fri, 27 Oct 2006, Adrian Bunk wrote:
>
> >On Thu, Oct 26, 2006 at 06:29:53PM -0400, Pavel Roskin wrote:
> >>Anyway, I don't think it's relevant to ndiswrapper.
> >>...
> >
> >All non-GPL'ed modules are in a grey area, and the question isn't
> >whether it's black or white but how light or dark the grey is...
>
> ndiswrapper is GPL, but is (with the current code) not allowed to use the
> gpl-only'ed symbols.
ndiswrapper is mostly a compatility layer for linking non-GPL'ed code
into the kernel.
This is really a grey area, and the legal status might depend on the
jurisdiction and the judge.
Considering the vivid "cease and desist" business in Germany, I wouldn't
be surprised if some day someone would start sending "cease and desist"
letters against mirrors in Germany distributing code in this grey
area...
> c'ya
> sven
cu
Adrian
--
"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
Andrew Morton wrote:
> May be so. But this patch was supposed to print a helpful taint message to
> draw our attention to the fact that ndis-wrapper was in use. The patch was
> not intended to cause gpl'ed modules to stop loading (or if is was, that
> effect was concealed from yours truly).
>
It's an unintended side effect of recent per-module-taint changes which
exposed the special nature of ndiswrapper & driverloader taints. Here's
where it went wrong:
Florin Malita wrote:
> No need to keep 'license_gplok' around anymore, it should be equivalent
> to !(taints & TAINT_PROPRIETARY_MODULE).
>
That turns out to be true for every module under the sun except
ndiswrapper & driverloader which are singled out and treated
differently: their proprietary taint has nothing to do with their license.
Randy's patch looks like a reasonable compromise to get them going again
- the alternative being the reintroduction of license_gplok or some
equivalent per-module flag just to support 2 hardcoded exceptions where
GPL incompatibility and proprietary tainting are not correlated.
---
fm
Hi Pavel!
On 27 Oct 2006, at 00:29, Pavel Roskin wrote:
>> EXPORT_SYMBOL_GPL shows a pretty clear intention, and offering
>> functionality provided throug h EXPORT_SYMBOL_GPL'ed symbols to
>> proprietary code sounds very fishy.
>
> Last time I checked, EXPORT_SYMBOL_GPL was an indication that a code
> using it will be considered as a work derived from Linux. This way,
> ndiswrapper, which is free software, can be considered a derived work.
>
> NDIS drivers don't know about any Linux API, therefore they cannot use
> it directly. The purpose of ndiswrapper is not to remove limitations
> from the Linux API, but to present a completely different API.
>
Maybe everyone would be more happy if this "completely different API"
would live at lower priviledge level, e.g. ring 1, so it could not
screw up kernel internals? Is this technically possible? Maybe it's
the same thing, but another way could be to run NDIS stuff inside a
xen-like virtual environment... Has anyone tried yet?
Ciao,
Roland
--
TU Muenchen, Physik-Department E18, James-Franck-Str., 85748 Garching
Telefon 089/289-12575; Telefax 089/289-12570
--
CERN office: 892-1-D23 phone: +41 22 7676540 mobile: +41 76 487 4482
--
Any society that would give up a little liberty to gain a little
security will deserve neither and lose both. - Benjamin Franklin
-----BEGIN GEEK CODE BLOCK-----
Version: 3.12
GS/CS/M/MU d-(++) s:+ a-> C+++ UL++++ P+++ L+++ E(+) W+ !N K- w--- M
+ !V Y+
PGP++ t+(++) 5 R+ tv-- b+ DI++ e+++>++++ h---- y+++
------END GEEK CODE BLOCK------
> >
> i've found:
>
> __create_workqueue
> queue_work
if you change the queue_work() calls to schedule_work() (and drop it's
first argument) and just remove the create_workqueue() entirely, does it
work then? (probably also need to remove destroy_workqueue() call)
if so, that's the real solution on the ndiswrapper side...
>
> ---
> From: Randy Dunlap <[email protected]>
>
> For ndiswrapper and driverloader, don't set the module->taints
> flags, just set the kernel global tainted flag.
> This should allow ndiswrapper to continue to use GPL symbols.
> Not tested.
can we put something in feature-removal that we'll undo this in say 6
months?
ndiswrapper is easy to fix to not use the internals of the queue_work
api, and just use schedule_work() instead. At that time the
functionality as a whole is still the right one.
(it's a separate question if ndiswrapper should be in this table;
driverloader should be, it's non-GPL at all, so that part of your patch
is broken)
--
if you want to mail me at work (you don't), use arjan (at) linux.intel.com
Test the interaction between Linux and your BIOS via http://www.linuxfirmwarekit.org
On Fri, 27 Oct 2006 16:24:58 +0200
Arjan van de Ven <[email protected]> wrote:
> > >
> > i've found:
> >
> > __create_workqueue
> > queue_work
>
>
> if you change the queue_work() calls to schedule_work() (and drop it's
> first argument) and just remove the create_workqueue() entirely, does it
> work then? (probably also need to remove destroy_workqueue() call)
> if so, that's the real solution on the ndiswrapper side...
>
>
Or maybe do equivalent delayed function calls by using a kthread.
On Fri, 27 Oct 2006 16:23:39 +0200 Arjan van de Ven wrote:
> > ---
> > From: Randy Dunlap <[email protected]>
> >
> > For ndiswrapper and driverloader, don't set the module->taints
> > flags, just set the kernel global tainted flag.
> > This should allow ndiswrapper to continue to use GPL symbols.
> > Not tested.
>
>
> can we put something in feature-removal that we'll undo this in say 6
> months?
It's open for discussion AFAIK.
> ndiswrapper is easy to fix to not use the internals of the queue_work
> api, and just use schedule_work() instead. At that time the
> functionality as a whole is still the right one.
> (it's a separate question if ndiswrapper should be in this table;
> driverloader should be, it's non-GPL at all, so that part of your patch
> is broken)
OK, here's the replacement for only ndiswrapper, not driverloader.
---
From: Randy Dunlap <[email protected]>
For ndiswrapper, don't set the module->taints flags,
just set the kernel global tainted flag.
This should allow ndiswrapper to continue to use GPL symbols.
Not tested.
Signed-off-by: Randy Dunlap <[email protected]>
---
kernel/module.c | 2 +-
1 files changed, 1 insertion(+), 1 deletion(-)
--- linux-2619-rc3-pv.orig/kernel/module.c
+++ linux-2619-rc3-pv/kernel/module.c
@@ -1718,7 +1718,7 @@ static struct module *load_module(void _
set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
if (strcmp(mod->name, "ndiswrapper") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
+ add_taint(TAINT_PROPRIETARY_MODULE);
if (strcmp(mod->name, "driverloader") == 0)
add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
Hi Roland,
On Fri, 2006-10-27 at 14:52 +0200, Roland Kuhn wrote:
> Maybe everyone would be more happy if this "completely different API"
> would live at lower priviledge level, e.g. ring 1, so it could not
> screw up kernel internals? Is this technically possible? Maybe it's
> the same thing, but another way could be to run NDIS stuff inside a
> xen-like virtual environment... Has anyone tried yet?
I think it would be better to move this discussion to ndiswrapper
<[email protected]>
I'm not familiar with the fine details of ndiswrapper implementation and
neither am I good at understanding memory management in Linux, but I
suspect it's not worth the trouble.
I believe there is no "ring 1" on x86_64 (unless it's in i386
compatibility mode). So it would work on i386 only. Maybe x86_64 could
use its "ring 3" equivalent, i.e. standard userspace permissions, but I
don't think it would be what you want.
Even on i386, I don't see an easy way to allocate executable memory with
ring 1 permissions. See include/asm-i386/pgtable.h.
I suspect that there is no support for running kernel code at anything
but "ring 0". What do you think are the chances that support for
low-privileged kernel code will be added to the kernel just for
ndiswrapper? I think the chances are pretty slim.
In the case of the PCI driver, some critical operations would have to be
passed to the NDIS driver, such as IRQ and DMA processing. It would be
better to make sure that the code has the necessary priority to do it
fast and correctly.
In the case of the USB driver, it may be better to go all the way to the
standard userspace. This would require a protocol to pass network API
to the userspace, including wireless extensions. I believe the work is
underway.
--
Regards,
Pavel Roskin
On Fri, 27 Oct 2006 08:27:41 -0700
Randy Dunlap <[email protected]> wrote:
> From: Randy Dunlap <[email protected]>
>
> For ndiswrapper, don't set the module->taints flags,
> just set the kernel global tainted flag.
> This should allow ndiswrapper to continue to use GPL symbols.
> Not tested.
>
> Signed-off-by: Randy Dunlap <[email protected]>
> ---
> kernel/module.c | 2 +-
> 1 files changed, 1 insertion(+), 1 deletion(-)
>
> --- linux-2619-rc3-pv.orig/kernel/module.c
> +++ linux-2619-rc3-pv/kernel/module.c
> @@ -1718,7 +1718,7 @@ static struct module *load_module(void _
> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>
> if (strcmp(mod->name, "ndiswrapper") == 0)
> - add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
> + add_taint(TAINT_PROPRIETARY_MODULE);
> if (strcmp(mod->name, "driverloader") == 0)
> add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>
Could someone please test this for us?
Arjan van de Ven wrote:
> (it's a separate question if ndiswrapper should be in this table;
> driverloader should be, it's non-GPL at all, so that part of your patch
> is broken)
>
If driverloader is not GPLed then why does it need to be treated
exceptionally to begin with? It taints the kernel anyway because of its
license.
---
fm
Andrew Morton wrote:
> On Fri, 27 Oct 2006 08:27:41 -0700
> Randy Dunlap <[email protected]> wrote:
>
>> Signed-off-by: Randy Dunlap <[email protected]>
>> ---
>> kernel/module.c | 2 +-
>> 1 files changed, 1 insertion(+), 1 deletion(-)
>>
>> --- linux-2619-rc3-pv.orig/kernel/module.c
>> +++ linux-2619-rc3-pv/kernel/module.c
>> @@ -1718,7 +1718,7 @@ static struct module *load_module(void _
>> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>>
>> if (strcmp(mod->name, "ndiswrapper") == 0)
>> - add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>> + add_taint(TAINT_PROPRIETARY_MODULE);
>> if (strcmp(mod->name, "driverloader") == 0)
>> add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>>
>>
>
> Could someone please test this for us?
>
Tested, works (ndiswrapper 1.27).
Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
redundant. How about removing it (applies on top of Randy's patch)?
Signed-off-by: Florin Malita <[email protected]>
---
module.c | 2 --
1 file changed, 2 deletions(-)
diff --git a/kernel/module.c b/kernel/module.c
index 67009bd..293eb4c 100644
--- a/kernel/module.c
+++ b/kernel/module.c
@@ -1719,8 +1719,6 @@ #endif
if (strcmp(mod->name, "ndiswrapper") == 0)
add_taint(TAINT_PROPRIETARY_MODULE);
- if (strcmp(mod->name, "driverloader") == 0)
- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
/* Set up MODINFO_ATTR fields */
setup_modinfo(mod, sechdrs, infoindex);
Florin Malita wrote:
> Andrew Morton wrote:
>> On Fri, 27 Oct 2006 08:27:41 -0700
>> Randy Dunlap <[email protected]> wrote:
>>
>>> Signed-off-by: Randy Dunlap <[email protected]>
>>> ---
>>> kernel/module.c | 2 +-
>>> 1 files changed, 1 insertion(+), 1 deletion(-)
>>>
>>> --- linux-2619-rc3-pv.orig/kernel/module.c
>>> +++ linux-2619-rc3-pv/kernel/module.c
>>> @@ -1718,7 +1718,7 @@ static struct module *load_module(void _
>>> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>>>
>>> if (strcmp(mod->name, "ndiswrapper") == 0)
>>> - add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>>> + add_taint(TAINT_PROPRIETARY_MODULE);
>>> if (strcmp(mod->name, "driverloader") == 0)
>>> add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>>>
>>>
>> Could someone please test this for us?
>>
>
> Tested, works (ndiswrapper 1.27).
Thanks.
> Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
> LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
> redundant. How about removing it (applies on top of Randy's patch)?
I agree.
> Signed-off-by: Florin Malita <[email protected]>
> ---
>
> module.c | 2 --
> 1 file changed, 2 deletions(-)
>
> diff --git a/kernel/module.c b/kernel/module.c
> index 67009bd..293eb4c 100644
> --- a/kernel/module.c
> +++ b/kernel/module.c
> @@ -1719,8 +1719,6 @@ #endif
>
> if (strcmp(mod->name, "ndiswrapper") == 0)
> add_taint(TAINT_PROPRIETARY_MODULE);
> - if (strcmp(mod->name, "driverloader") == 0)
> - add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>
> /* Set up MODINFO_ATTR fields */
> setup_modinfo(mod, sechdrs, infoindex);
>
>
--
~Randy
Ar Gwe, 2006-10-27 am 18:56 -0400, ysgrifennodd Florin Malita:
> Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
> LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
> redundant. How about removing it (applies on top of Randy's patch)?
>
>
> Signed-off-by: Florin Malita <[email protected]>
NAK
Older versions of Linuxant's driverloader claim GPL\0some other text and
systematically set out to abuse the license tag code. We should continue
to carry the code for this.
Alan
Alan Cox wrote:
> Ar Gwe, 2006-10-27 am 18:56 -0400, ysgrifennodd Florin Malita:
>> Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
>> LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
>> redundant. How about removing it (applies on top of Randy's patch)?
>>
>>
>> Signed-off-by: Florin Malita <[email protected]>
>
> NAK
>
> Older versions of Linuxant's driverloader claim GPL\0some other text and
> systematically set out to abuse the license tag code. We should continue
> to carry the code for this.
>
> Alan
I'm confused. Do you mean that we should continue to treate driverloader
as GPL? Oh, I guess I see. You mean that we should continue to have
special code to override their "GPL\0other text" license. OK.
--
~Randy
Alan Cox wrote:
> Ar Gwe, 2006-10-27 am 18:56 -0400, ysgrifennodd Florin Malita:
>
>> Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
>> LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
>> redundant. How about removing it (applies on top of Randy's patch)?
>>
>>
>> Signed-off-by: Florin Malita <[email protected]>
>>
>
> NAK
>
> Older versions of Linuxant's driverloader claim GPL\0some other text and
> systematically set out to abuse the license tag code. We should continue
> to carry the code for this.
>
Older versions of driverloader won't even build for recent kernels
(actually even the latest - 2.34 - fails with 2.6.19-rc3). Do you know
of any driverloader version that actually works with 2.6.18+ and
misrepresents its license? Seems to me they gave up that practice and
currently the check is useless but if you want to keep it as a statement
I can understand that :)
---
fm
On 2006-10-27, Alan Cox <[email protected]> wrote:
> Ar Gwe, 2006-10-27 am 18:56 -0400, ysgrifennodd Florin Malita:
>> Also, since driverloader is not GPL-compatible (MODULE_LICENSE("see
>> LICENSE file; Copyright (c)2003-2004 Linuxant inc.")), that check is
>> redundant. How about removing it (applies on top of Randy's patch)?
>>
>>
>> Signed-off-by: Florin Malita <[email protected]>
>
> NAK
>
> Older versions of Linuxant's driverloader claim GPL\0some other text and
> systematically set out to abuse the license tag code. We should continue
> to carry the code for this.
>
> Alan
>
ACK this NACK.
Please, do not forget:
Message-ID: <[email protected]>
<http://permalink.gmane.org/gmane.linux.kernel/201265>
____
Andrew Morton wrote:
>On Fri, 27 Oct 2006 08:27:41 -0700
>Randy Dunlap <[email protected]> wrote:
>
>
>
>>From: Randy Dunlap <[email protected]>
>>
>>For ndiswrapper, don't set the module->taints flags,
>>just set the kernel global tainted flag.
>>This should allow ndiswrapper to continue to use GPL symbols.
>>Not tested.
>>
>>Signed-off-by: Randy Dunlap <[email protected]>
>>---
>> kernel/module.c | 2 +-
>> 1 files changed, 1 insertion(+), 1 deletion(-)
>>
>>--- linux-2619-rc3-pv.orig/kernel/module.c
>>+++ linux-2619-rc3-pv/kernel/module.c
>>@@ -1718,7 +1718,7 @@ static struct module *load_module(void _
>> set_license(mod, get_modinfo(sechdrs, infoindex, "license"));
>>
>> if (strcmp(mod->name, "ndiswrapper") == 0)
>>- add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>>+ add_taint(TAINT_PROPRIETARY_MODULE);
>> if (strcmp(mod->name, "driverloader") == 0)
>> add_taint_module(mod, TAINT_PROPRIETARY_MODULE);
>>
>>
>>
>
>Could someone please test this for us
>
>
tested on rc2-mm2. It works.
I think it would be really good to hear somebody from the ndiswrapper
group about this thread. During these 6 months (?) i believe both the
kernel and ndiswrapper could go very far with a good collaboration.
Another thing: shouldnt be more efficent and readable to remove those
"if ((strcmp...." from modules.c and to put all the tainted modules
names into a separate source file into, say, a string array ? What if we
had 250 tainted modules ?
And finally, it seems to me that ideas are not perfectly clear about
what Linux should / should not do in respect to
- GPLed
- NON GPLed
- (???) GPLed
drivers. I believe policies and potential problems should be cristal
clear before making any implementation.
Regards,
Gianluca