[PATCH] Blacklist binary-only modules lying about their license
Carl-Daniel Hailfinger
LinuxAnt offers binary only modules without any sources. To circumvent our
MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
LICENSE file applies");
Since string comparisons stop at the first "\0" character, the kernel is
tricked into thinking the modules are GPL. Btw, the "GPL" directory they
are speaking about is empty.
The attached patch blacklists all modules having "Linuxant" or "Conexant"
in their author string. This may seem a bit broad, but AFAIK both
companies never have released anything under the GPL and have a strong
history of binary-only modules.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Gilles May
>The attached patch blacklists all modules having "Linuxant" or "Conexant"
>in their author string. This may seem a bit broad, but AFAIK both
>companies never have released anything under the GPL and have a strong
>history of binary-only modules.
>
>
Blacklisting modules?!
Oh come on!
I agree the '\0' trick is not really nice, but blacklisting modules is
not really better. It's not a functionality that adds anything to the
kernel.
If ppl want/have to use that module let them!
Take care, Gilles
--
If you don't live for something you'll die for nothing!
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majo...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Linus Torvalds
On Tue, 27 Apr 2004, Carl-Daniel Hailfinger wrote:
>
> LinuxAnt offers binary only modules without any sources. To circumvent our
> MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
>
> MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> LICENSE file applies");
Hey, that is interesting in itself, since playing the above kinds of games
makes it pretty clear to everybody that any infringement was done
wilfully. They should be talking to their lawyers about things like that.
Anyway, I suspect that rather than blacklist bad people, I'd much prefer
to have the module tags be done as counted strings instead. It should be
easy enough to do by just having the macro prepend a "sizeof(xxxx)"
thing or something.
Hmm. At least with -sdt=c99 it should be trivial, with something like
#define __MODULE_INFO(tag, name, info) \
static struct { int len; const char value[] } \
__module_cat(name,__LINE__) __attribute_used__ \
__attribute__((section(".modinfo"),unused)) = \
{ sizeof(__stringify(tag) "=" info), \
__stringify(tag) "=" info }
doing the job.
That should make it pretty easy to parse the .modinfo section too.
Linus
Zwane Mwaikambo
> Carl-Daniel Hailfinger wrote:
>
> >The attached patch blacklists all modules having "Linuxant" or "Conexant"
> >in their author string. This may seem a bit broad, but AFAIK both
> >companies never have released anything under the GPL and have a strong
> >history of binary-only modules.
> >
> >
> Blacklisting modules?!
>
> Oh come on!
> I agree the '\0' trick is not really nice, but blacklisting modules is
> not really better. It's not a functionality that adds anything to the
> kernel.
> If ppl want/have to use that module let them!
Then they should list themselves as proprietory, there will be no problem
loading them in that case. No need to tell fibs.
Willy Tarreau
> Hi,
>
> LinuxAnt offers binary only modules without any sources. To circumvent our
> MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
>
> MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> LICENSE file applies");
Funny, this reminds me of VGA BIOSes which put "IBM Compatible" at the right
location, because lots of programs were looking for "IBM" to check if this
way such a bios. Same check, same workaround :-) I hope they have patented
this trick so that they will be the only ones using it :-)
> The attached patch blacklists all modules having "Linuxant" or "Conexant"
> in their author string. This may seem a bit broad, but AFAIK both
> companies never have released anything under the GPL and have a strong
> history of binary-only modules.
What would be smarter would be to try to understand why they do this. At
the moment, it seems to me that their only problem is to taint the kernel.
Why ? I don't this that any old modutils/module-utils found in any distros
don't load properly such modules. So perhaps they only want not to taint
the kernel because it appears dirty to their customers who will not receive
any more support from LKML. So perhaps what we really need is to add a new
MODULE_SUPPORT field stating where to get support from in case of bugs,
oopses or panics on a tainted kernel. Thus, the module author would be able
to insert something such as "suppo...@author.com" which will be displayed
on each oops/panic/etc... Even if this is a long list because the customer
uses connexant, nvidia, checkpoint and I don't know what, at least he will
get 3 email addresses for his support. And it might reassure these authors
to know that the customer will ask them before asking us with our automatic
replies "unload your binary modules...".
Anyway it now seems like strings will have to be matched on their lenghts...
Regards,
Willy
Rusty Russell
> Anyway, I suspect that rather than blacklist bad people, I'd much prefer
> to have the module tags be done as counted strings instead. It should be
> easy enough to do by just having the macro prepend a "sizeof(xxxx)"
> thing or something.
>
> Hmm. At least with -sdt=c99 it should be trivial, with something like
>
> #define __MODULE_INFO(tag, name, info) \
> static struct { int len; const char value[] } \
> __module_cat(name,__LINE__) __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = \
> { sizeof(__stringify(tag) "=" info), \
> __stringify(tag) "=" info }
>
> doing the job.
Cute, but breaks the "modinfo" tool unfortunately. I'd prefer not to do
that. Since they want to circumvent this, almost anything we want to do
is a waste of time.
Rusty.
Name: Stop most obvious abuse of MODULE_LICENSE
Status: Tested on 2.6.6-rc2-bk4
Arms race forces bloat upon module users.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .31262-linux-2.6.6-rc2-bk4/include/linux/module.h .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h
--- .31262-linux-2.6.6-rc2-bk4/include/linux/module.h 2004-04-22 08:03:55.000000000 +1000
+++ .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h 2004-04-27 15:52:19.000000000 +1000
@@ -16,6 +16,9 @@
#include <linux/kmod.h>
#include <linux/elf.h>
#include <linux/stringify.h>
+#include <linux/init.h>
+#include <linux/kernel.h>
+#include <linux/compiler.h>
#include <asm/local.h>
#include <asm/module.h>
@@ -61,7 +64,14 @@ void sort_main_extable(void);
#ifdef MODULE
#define ___module_cat(a,b) __mod_ ## a ## b
#define __module_cat(a,b) ___module_cat(a,b)
+/* Some sick fucks embeded NULs in MODULE_LICENSE to circumvent checks. */
+#define __MODULE_INFO_CHECK(info) \
+ static void __init __attribute_used__ \
+ __module_cat(__mc_,__LINE__)(void) { \
+ BUILD_BUG_ON(__builtin_strlen(info) + 1 != sizeof(info)); \
+ }
#define __MODULE_INFO(tag, name, info) \
+__MODULE_INFO_CHECK(info); \
static const char __module_cat(name,__LINE__)[] \
__attribute_used__ \
__attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
Grzegorz Piotr Jaskiewicz
>What would be smarter would be to try to understand why they do this. At
>the moment, it seems to me that their only problem is to taint the kernel.
>Why ? I don't this that any old modutils/module-utils found in any distros
>don't load properly such modules. So perhaps they only want not to taint
>the kernel because it appears dirty to their customers who will not receive
>any more support from LKML. So perhaps what we really need is to add a new
>MODULE_SUPPORT field stating where to get support from in case of bugs,
>oopses or panics on a tainted kernel. Thus, the module author would be able
>to insert something such as "suppo...@author.com" which will be displayed
>on each oops/panic/etc... Even if this is a long list because the customer
>uses connexant, nvidia, checkpoint and I don't know what, at least he will
>get 3 email addresses for his support. And it might reassure these authors
>to know that the customer will ask them before asking us with our automatic
>replies "unload your binary modules...".
>
>Anyway it now seems like strings will have to be matched on their lenghts...
>
>
And they will put linux-...@vger.kernel(.org) there :-)
You never know...
--
GJ
Jan-Benedict Glaw
wrote in message <1083045844.2150.105.camel@bach>:
> On Tue, 2004-04-27 at 14:31, Linus Torvalds wrote:
> diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .31262-linux-2.6.6-rc2-bk4/include/linux/module.h .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h
> --- .31262-linux-2.6.6-rc2-bk4/include/linux/module.h 2004-04-22 08:03:55.000000000 +1000
> +++ .31262-linux-2.6.6-rc2-bk4.updated/include/linux/module.h 2004-04-27 15:52:19.000000000 +1000
> #ifdef MODULE
> #define ___module_cat(a,b) __mod_ ## a ## b
> #define __module_cat(a,b) ___module_cat(a,b)
> +/* Some sick fucks embeded NULs in MODULE_LICENSE to circumvent checks. */
> +#define __MODULE_INFO_CHECK(info) \
> + static void __init __attribute_used__ \
> + __module_cat(__mc_,__LINE__)(void) { \
> + BUILD_BUG_ON(__builtin_strlen(info) + 1 != sizeof(info)); \
> + }
> #define __MODULE_INFO(tag, name, info) \
> +__MODULE_INFO_CHECK(info); \
> static const char __module_cat(name,__LINE__)[] \
> __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = __stringify(tag) "=" info
Erm, that's a pure compile-time check, which the companies can remove.
So they can still put their fucked up license string into the module,
customer's kernel won't detect it.
So I'm full for embedding the supplied string's size into the module, or
some compile-time generated checksum. We need something that can be
checked at module load time, not at compile time, or do I misread the
code?
MfG, JBG
--
Jan-Benedict Glaw jbg...@lug-owl.de . +49-172-7608481
"Eine Freie Meinung in einem Freien Kopf | Gegen Zensur | Gegen Krieg
fuer einen Freien Staat voll Freier Bürger" | im Internet! | im Irak!
ret = do_actions((curr | FREE_SPEECH) & ~(NEW_COPYRIGHT_LAW | DRM | TCPA));
Carl-Daniel Hailfinger
> On Tue, 27 Apr 2004, Gilles May wrote:
>
>
>>Carl-Daniel Hailfinger wrote:
>>
>>
>>>The attached patch blacklists all modules having "Linuxant" or "Conexant"
>>>in their author string. This may seem a bit broad, but AFAIK both
>>>companies never have released anything under the GPL and have a strong
>>>history of binary-only modules.
>>>
>>>
>>
>>Blacklisting modules?!
>>
>>Oh come on!
>>I agree the '\0' trick is not really nice, but blacklisting modules is
>>not really better. It's not a functionality that adds anything to the
>>kernel.
>>If ppl want/have to use that module let them!
If you had read the patch instead of complaining, you would have seen that
the only change is to taint the kernel for those modules.
> Then they should list themselves as proprietory, there will be no problem
> loading them in that case. No need to tell fibs.
Indeed.
Carl-Daniel
--
http://www.hailfinger.org/
Carl-Daniel Hailfinger
# objdump -t forcedeth.ko |grep '\.modinfo'|sort
00000000 l d .modinfo 00000000
00000000 l O .modinfo 0000000c __mod_license1618
00000020 l O .modinfo 00000036 __mod_description1617
00000060 l O .modinfo 00000031 __mod_author1616
000000a0 l O .modinfo 00000047 __mod_max_interrupt_work1614
00000100 l O .modinfo 0000002b __mod_alias58
00000140 l O .modinfo 0000002b __mod_alias57
00000180 l O .modinfo 0000002b __mod_alias56
000001ab l O .modinfo 00000009 __module_depends
000001c0 l O .modinfo 0000002d __mod_vermagic5
Wouldn't it be possible to check the length info from the module symbol
table and compare it with the strlen for the corresponding symbol? If that
gives us a mismatch, refuse to load the module (or mark it as
proprietary). Additionally, check that nothing but NULLs is used as
padding between the strings.
This way, the module format doesn't change, but we can do additional
verification in the loader.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
-
Paulo Marques
>
> This way, the module format doesn't change, but we can do additional
> verification in the loader.
>
I agree with Rusty Russell. Anything that we do can be circunvented.
If they are really into it, they can build a small tool to change the symbol
information from the module.
The way I see it, they know a C string ends with a '\0'. This is like saying
that a English sentence ends with a dot. If they wrote "GPL\0" they are
effectively saying that the license *is* GPL period.
So, where the source code? :)
--
Paulo Marques - www.grupopie.com
"In a world without walls and fences who needs windows and gates?"
Jan-Benedict Glaw
wrote in message <408E5944...@grupopie.com>:
> Carl-Daniel Hailfinger wrote:
> >This way, the module format doesn't change, but we can do additional
> >verification in the loader.
>
> saying that a English sentence ends with a dot. If they wrote "GPL\0" they
> are effectively saying that the license *is* GPL period.
>
> So, where the source code? :)
That's another (quite amusing:) point of view. Anybody willing to ask a
lawyer?
Tim Connors
>
> --+sHJum3is6Tsg7/J
> Content-Type: text/plain; charset=iso-8859-1
> Content-Disposition: inline
> Content-Transfer-Encoding: quoted-printable
>
> On Tue, 2004-04-27 13:59:48 +0100, Paulo Marques <pmar...@grupopie.com>
> wrote in message <408E5944...@grupopie.com>:
> > Carl-Daniel Hailfinger wrote:
> > >This way, the module format doesn't change, but we can do additional
> > >verification in the loader.
> > The way I see it, they know a C string ends with a '\0'. This is like=20
> > saying that a English sentence ends with a dot. If they wrote "GPL\0" the=
> y=20
> > are effectively saying that the license *is* GPL period.
> > So, where the source code? :)
>
> That's another (quite amusing:) point of view. Anybody willing to ask a
> lawyer?
In the wonderful Good Ol USofA, I think it would be trivial to apply
the DMCA: A character string following the appropriate convention
(null termination) is a protection mechanism.
Breaking that convention is a cicumvention device.
If it can work for XOR, and gets someone thrown in prison for 12
months, surely it will work for null termination?
Pretty clear cut, so, who's going to write this lovely company a
letter/send in the land-sharks (someone better, otherwise companies
will realise very quickly that they can stamp all over us with no
retribution[1])? I don't own any relevant copyright, unfortunately.
[1] Has anything been done about the other members on the hall or
shame?
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
HANDLE WITH EXTREME CARE: This Product Contains Minute Electrically
Charged Particles Moving at Velocities in Excess of Five Hundred
Million Miles Per Hour.
Albert Cahalan
This is simple, really: since a C string ends at the
'\0', the module has been declared to be GPL code.
We shouldn't care if that C string is part of a larger
array. This is a damn obvious case of willful circumvention
of copyright control, access control, digital rights
management, etc.
Unleash the sharks.
Jon
> I don't see a need to get all complicated about this.
> This is simple, really: since a C string ends at the
> '\0', the module has been declared to be GPL code.
> We shouldn't care if that C string is part of a larger
> array. This is a damn obvious case of willful circumvention
> of copyright control, access control, digital rights
> management, etc.
>
> Unleash the sharks.
>
http://developers.slashdot.org/article.pl?sid=04/04/27/1435217
--
Jon
http://tesla.resnet.mtu.edu
The only meaning in life is the meaning you create for it.
Marc Boucher
On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
> Hi,
>
> LinuxAnt offers binary only modules without any sources.
Not true. Linuxant modules come with full source for operating-system specific
code.
> To circumvent our
> MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
>
> MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> LICENSE file applies");
Paulo Marques said:
> The way I see it, they know a C string ends with a '\0'. This is like saying
> that a English sentence ends with a dot. If they wrote "GPL\0" they are
> effectively saying that the license *is* GPL period.
>
> So, where the source code? :)
Unfortunately Linuxant cannot release the source for the proprietary portions
of the Conexant HCF and HSF softmodem drivers, because it does not own these
parts and the terms under which they have been licensed from Conexant prohibit
it.
We have tried to attenuate the inconvenience of these restrictions by isolating
the proprietary code and releasing source for all operating-system specific
code, so that people can rebuild the modules for any kernel.
I believe that this is a fair compromise. Otherwise, it wouldn't be possible to
use Conexant softmodems under Linux right now, since 1) the hardware is quite
obscure, 2) no-one has fully implemented the modulations (such as V.92 etc..)
and related protocols (V.44/V.42[bis]) for free, because this stuff is quite
complex and involves many patents. Before blaming Conexant for protecting their
intellectual property, one should note that as far as I know none of the
other softmodem manufacturers (Lucent/Agere, SmartLink, Motorola, PC-Tel etc..)
have ever accepted to give the source code away for their proprietary
implementations of modem modulations either.
Willy Tarreau <willy () w ! ods ! org> wrote:
> Funny, this reminds me of VGA BIOSes which put "IBM Compatible" at the right
> location, because lots of programs were looking for "IBM" to check if this
> way such a bios. Same check, same workaround :-) I hope they have patented
> this trick so that they will be the only ones using it :-)
>
> > The attached patch blacklists all modules having "Linuxant" or "Conexant"
> > in their author string. This may seem a bit broad, but AFAIK both
> > companies never have released anything under the GPL and have a strong
> > history of binary-only modules.
>
> What would be smarter would be to try to understand why they do this.
>
Exactly. Linuxant's intent is NOT to circumvent any license checks (see
below for why this specific workaround was put in) which would be unnecessary
since the drivers in question do not use any GPL_ONLY functions, as far as
I know.
> At
> the moment, it seems to me that their only problem is to taint the kernel.
Actually, we also have no desire nor purpose to prevent tainting. The purpose
of the workaround is to avoid repetitive warning messages generated when
multiple modules belonging to a single logical "driver" are loaded (even when
a module is only probed but not used due to the hardware not being present).
Although the issue may sound trivial/harmless to people on the lkml, it was a
frequent cause of confusion for the average person.
Other Linuxant drivers (like DriverLoader and Riptide) do not need nor use this
workaround because they are not composed of multiple modules and one set of
warning messages is usually bearable.
> Why ? I don't this that any old modutils/module-utils found in any distros
> don't load properly such modules. So perhaps they only want not to taint
> the kernel because it appears dirty to their customers who will not receive
> any more support from LKML. So perhaps what we really need is to add a new
> MODULE_SUPPORT field stating where to get support from in case of bugs,
> oopses or panics on a tainted kernel. Thus, the module author would be able
> to insert something such as "suppo...@author.com" which will be displayed
> on each oops/panic/etc... Even if this is a long list because the customer
> uses connexant, nvidia, checkpoint and I don't know what, at least he will
> get 3 email addresses for his support. And it might reassure these authors
> to know that the customer will ask them before asking us with our automatic
> replies "unload your binary modules...".
Linuxant would very much welcome such steps to improve the current situation,
and is willing to eliminate workarounds once they are no longer necessary.
Sincerely,
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
Juergen E. Fischer
On Tue, Apr 27, 2004 at 13:59:48 +0100, Paulo Marques wrote:
> The way I see it, they know a C string ends with a '\0'. This is like
> saying that a English sentence ends with a dot. If they wrote "GPL\0" they
> are effectively saying that the license *is* GPL period.
>
> So, where the source code? :)
IANAL, but I think the copyright holder is not bound to the GPL and can
supply what ever he wants, just the licensee is required to make the
source available.
Jürgen
Adam Jaskiewicz
>Actually, we also have no desire nor purpose to prevent tainting. The purpose
>of the workaround is to avoid repetitive warning messages generated when
>multiple modules belonging to a single logical "driver" are loaded (even when
>a module is only probed but not used due to the hardware not being present).
>Although the issue may sound trivial/harmless to people on the lkml, it was a
>frequent cause of confusion for the average person.
>
what
the error messages mean, rather than working around the liscense checking
code? Educate the users, rather than fibbing.
--
Adam Jaskiewicz
Marc Boucher
Hi Adam,
On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>> Actually, we also have no desire nor purpose to prevent tainting. The
>> purpose
>> of the workaround is to avoid repetitive warning messages generated
>> when
>> multiple modules belonging to a single logical "driver" are loaded
>> (even when
>> a module is only probed but not used due to the hardware not being
>> present).
>> Although the issue may sound trivial/harmless to people on the lkml,
>> it was a
>> frequent cause of confusion for the average person.
>>
> Would it not be better to simply place a notice in the readme
> explaining what
> the error messages mean, rather than working around the liscense
> checking
> code? Educate the users, rather than fibbing.
Good idea. We will try to clarify the matter in the docs for the next
release.
A lot of users don't read them though, so a proper fix remains
necessary..
Regards
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
>
Chris Friesen
> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>> Would it not be better to simply place a notice in the readme
>> explaining what
>> the error messages mean, rather than working around the liscense checking
>> code? Educate the users, rather than fibbing.
>
>
> Good idea. We will try to clarify the matter in the docs for the next
> release.
> A lot of users don't read them though, so a proper fix remains necessary..
Does your company honestly feel that misleading the module loading tools is actually the proper way
to work around the issue of repetitive warning messages? This is blatently misleading and does not
reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.
A "proper fix" begins with not attempting to mislead the kernel/tools about the license...
Chris
Grzegorz Kulewski
> Marc Boucher wrote:
>
> > On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
> >> Would it not be better to simply place a notice in the readme
> >> explaining what
> >> the error messages mean, rather than working around the liscense checking
> >> code? Educate the users, rather than fibbing.
> >
> >
> > Good idea. We will try to clarify the matter in the docs for the next
> > release.
> > A lot of users don't read them though, so a proper fix remains necessary..
>
> Does your company honestly feel that misleading the module loading tools is actually the proper way
> to work around the issue of repetitive warning messages? This is blatently misleading and does not
> reflect well, especially when the "GPL" directory mentioned in the source string is actually empty.
>
> A "proper fix" begins with not attempting to mislead the kernel/tools about the license...
Maybe kernel should display warning only once per given licence or even
once per boot (who needs warning about tainting tainted kernel?)
Grzegorz Kulewski
Chris Friesen
> Maybe kernel should display warning only once per given licence or even
> once per boot (who needs warning about tainting tainted kernel?)
I think that's a very good point. If the kernel is already tainted, maybe we don't need to print
out additional taint messages.
Chris
Marc Boucher
On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
> Marc Boucher wrote:
>
>> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>>> Would it not be better to simply place a notice in the readme
>>> explaining what
>>> the error messages mean, rather than working around the liscense
>>> checking
>>> code? Educate the users, rather than fibbing.
>> Good idea. We will try to clarify the matter in the docs for the next
>> release.
>> A lot of users don't read them though, so a proper fix remains
>> necessary..
>
> Does your company honestly feel that misleading the module loading
> tools is actually the proper way to work around the issue of
> repetitive warning messages? This is blatently misleading and does
> not reflect well, especially when the "GPL" directory mentioned in the
> source string is actually empty.
It is a purely technical workaround. There is nothing misleading to the
human eye,
and the GPL directory isn't empty; it is included in full in our
generic .tar.gz, rpm and
.deb packages.
Marc
--
Marc Boucher
President
Linuxant inc.
http://www.linuxant.com
-
Chris Friesen
>
>
> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>> Does your company honestly feel that misleading the module loading
>> tools is actually the proper way to work around the issue of
>> repetitive warning messages? This is blatently misleading and does
>> not reflect well, especially when the "GPL" directory mentioned in the
>> source string is actually empty.
>
>
> It is a purely technical workaround. There is nothing misleading to the
> human eye,
modinfo reports a GPL license, and the kernel does not report itself as tainted. That's misleading.
> and the GPL directory isn't empty; it is included in full in our generic
> .tar.gz, rpm and
> .deb packages.
My apologies. I was going on the word of the original poster.
Chris
Valdis.K...@vt.edu
> Maybe kernel should display warning only once per given licence or even
> once per boot (who needs warning about tainting tainted kernel?)
If your kernel is tainted by 3 different modules, it saves you 2 reboots when
trying to replicate a problem with an untainted kernel.
Other than that, there's probably no reason to complain on a re-taint.
Steve Lee
they just
be written to syslog? Then it wouldn't matter if there were several
taint
messages. For example, I know my nVidia driver taints the kernel, I
don't need
to see that message over and over again.
Marc Boucher <marc () linuxant ! com> wrote:
> Actually, we also have no desire nor purpose to prevent tainting. The
purpose
> of the workaround is to avoid repetitive warning messages generated
when
> multiple modules belonging to a single logical "driver" are loaded
(even when
> a module is only probed but not used due to the hardware not being
present).
> Although the issue may sound trivial/harmless to people on the lkml,
it was a
> frequent cause of confusion for the average person.
Jorge Bernal (Koke)
> On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
> > Maybe kernel should display warning only once per given licence or even
> > once per boot (who needs warning about tainting tainted kernel?)
>
> If your kernel is tainted by 3 different modules, it saves you 2 reboots
> when trying to replicate a problem with an untainted kernel.
>
what about something like a /proc/tainted list of modules?
> Other than that, there's probably no reason to complain on a re-taint.
Grzegorz Kulewski
> On Martes, 27 de Abril de 2004 20:54, Valdis.K...@vt.edu wrote:
> > On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
> > > Maybe kernel should display warning only once per given licence or even
> > > once per boot (who needs warning about tainting tainted kernel?)
> >
> > If your kernel is tainted by 3 different modules, it saves you 2 reboots
> > when trying to replicate a problem with an untainted kernel.
> >
>
> what about something like a /proc/tainted list of modules?
I think that /proc/tainted would be better than spamming logs after each
load of tainted module...
But probably modules should not be removed from /proc/tainted on unloading
(to prevent from "un-tainting" the kernel by "clever" users).
Grzegorz Kulewski
Tigran Aivazian
> Instead of printing module taint messages to the screen, why couldn't
> they just
> be written to syslog? Then it wouldn't matter if there were several
> taint
> messages. For example, I know my nVidia driver taints the kernel, I
> don't need
> to see that message over and over again.
Yes, that is exactly what it was a few years ago when I checked (and
probably still is) --- a bug in modutils which needs to be fixed as those
messages are too annoying and aggressive. It should be changed to be made
possible to disable them via /etc/syslog.conf because a normal user
wouldn't have a clue how to disable them otherwise.
Those kind of "kernel messages" should not be seen except when a user
wants to prepare a bug report and send it to linux-kernel. Then he ought
to check dmesg and discover that he is in fact running binary only modules
and also he will discover the support email address and send his report
there instead of here.
Generally, breaking Unix philosophy with such aggressive messages
bypassing standard interfaces is what normally happens in commercial
Unix-es, which are driven by "market requirements" i.e. dictated by people
who have no clue what proper Unix is or should be. So, this part of
modutils is, ironically, very much anti-Linux and "commercial Unix"-like,
although it tries to look precisely opposite. It should be fixed, imho.
I even think that the whole "EXPORT_SYMBOL" vs "EXPORT_SYMBOL_GPL" thing
is moot and anti-freedom because it violates ability of hackers (even if
they happen to work for companies producing binary-only modules, that's
irrelevant) to make proper technical design decisions and instead obey
some person's idea of what is a "good" or "bad" caller of his API. But so
be it, since that's the way Linus and others prefers Linux to be.
Kind regards
Tigran
Jorge Bernal (Koke)
>
> I think that /proc/tainted would be better than spamming logs after each
> load of tainted module...
> But probably modules should not be removed from /proc/tainted on unloading
> (to prevent from "un-tainting" the kernel by "clever" users).
>
2 ideas:
Printing if the tainted module is loaded or unloaded
and/or
using the /proc/tainted interface to enable/disable loading of tainted
modules.
So that are 2 different things: a) how do we handle the tainted mods
notifications and b) if we let the user decide if he/she wants tainted
modules to be "blocked"
Tigran Aivazian
> A lot of users don't read them though, so a proper fix remains
> necessary..
Looking at some very very old scripts I wrote for clean loading binary
modules I see some code to fix this:
dmesg -n 1
# do the module loading
dmesg -n 6
But, it assumes the syslog/klog is not running (well, you can temporarily
stop it) and also it starts minilogd temporarily and then kills it and
restarts syslog/klog.
Try it and see if it works for you. About 2-3 years ago it definitely
worked :)
Kind regards
Tigran
Valdis.K...@vt.edu
> 2 ideas:
>
> Printing if the tainted module is loaded or unloaded
We already have a message when it's loading, and a message on unload is
superfluous - if I insmod the NVidia driver and then unload it, the kernel is
still tainted by it, because it had a chance to mangle memory while it was
loaded.
And yes, sometimes the damage can be hiding for a LONG time - I know I've seen
bug reports on the list that involved "module A dorked a pointer which wasn't
noticed for 3 days until module B tried to...."
Would the attached strawman patch make people happ(y|ier)?
--- linux-2.6.6-rc2-mm2/kernel/module.c.orig 2004-04-27 09:56:22.000000000 -0400
+++ linux-2.6.6-rc2-mm2/kernel/module.c 2004-04-27 16:16:59.764158885 -0400
@@ -1131,7 +1131,7 @@ static void set_license(struct module *m
mod->license_gplok = license_is_gpl_compatible(license);
if (!mod->license_gplok) {
- printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
+ printk(KERN_NOTICE "%s: module license '%s' taints kernel.\n",
mod->name, license);
tainted |= TAINT_PROPRIETARY_MODULE;
}
Timothy Miller
Chris Friesen wrote:
> Grzegorz Kulewski wrote:
>
>> Maybe kernel should display warning only once per given licence or
>> even once per boot (who needs warning about tainting tainted kernel?)
>
>
> I think that's a very good point. If the kernel is already tainted,
> maybe we don't need to print out additional taint messages.
>
That could be confusing if it's important for the user to know which
modules taint the kernel. If tainting is only mentioned for the first
tainting, then the user might be lead to believe that subsquent ones do
not taint the kernel, even though they do.
Timothy Miller
Chris Friesen wrote:
> Marc Boucher wrote:
>
>>
>>
>> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>
>
>>> Does your company honestly feel that misleading the module loading
>>> tools is actually the proper way to work around the issue of
>>> repetitive warning messages? This is blatently misleading and does
>>> not reflect well, especially when the "GPL" directory mentioned in
>>> the source string is actually empty.
>>
>>
>>
>> It is a purely technical workaround. There is nothing misleading to
>> the human eye,
>
>
> modinfo reports a GPL license, and the kernel does not report itself as
> tainted. That's misleading.
>
>> and the GPL directory isn't empty; it is included in full in our
>> generic .tar.gz, rpm and
>> .deb packages.
>
>
> My apologies. I was going on the word of the original poster.
Even that is a violation of the GPL. You can't link closed-source code
with GPL code and release it legally.
Binary-only modules are technically a violation of the GPL, but kernel
developers have chosen to allow it under tight constraints.
But the building and releasing ANYTHING which is made up of GPL code and
closed-source code and released as an atomic unit (not merely agregated
on the same medium) is illegal.
Grzegorz Kulewski
> Chris Friesen wrote:
> > Grzegorz Kulewski wrote:
> >> Maybe kernel should display warning only once per given licence or
> >> even once per boot (who needs warning about tainting tainted kernel?)
> >
> > I think that's a very good point. If the kernel is already tainted,
> > maybe we don't need to print out additional taint messages.
>
> That could be confusing if it's important for the user to know which
> modules taint the kernel. If tainting is only mentioned for the first
> tainting, then the user might be lead to believe that subsquent ones do
> not taint the kernel, even though they do.
Ok, so we can write big and fat KERNEL WAS JUST TAINTED warning on first
tainting module load and then issue only small notices to the log...
Grzegorz Kulewski
Junio C Hamano
PM> The way I see it, they know a C string ends with a '\0'. This is like
PM> saying that a English sentence ends with a dot. If they wrote "GPL\0"
PM> they are effectively saying that the license *is* GPL period.
PM> So, where the source code? :)
I do not know if their having "GPL\0" in their object makes it
under GPL, but even if it did, I do not think they have any
obligation to give us the source. GPL says "You may do such and
such provided if you do so and so" but that is all about the
Licensee. It does not talk anything about what the copyright
holder may, may not, nor must do :).
Valdis.K...@vt.edu
> under GPL, but even if it did, I do not think they have any
> obligation to give us the source. GPL says "You may do such and
> such provided if you do so and so" but that is all about the
> Licensee. It does not talk anything about what the copyright
> holder may, may not, nor must do :).
Remember however that it's *really* difficult to create a kernel module
that's not a derivative work of the kernel - and for *that* side of
the fence, they are indeed a licensee of the kernel source tree, not
the copyright holder of their code....
Robert M. Stockmann
On Mon, 26 Apr 2004, Linus Torvalds wrote:
> On Tue, 27 Apr 2004, Carl-Daniel Hailfinger wrote:
> >
> > LinuxAnt offers binary only modules without any sources. To circumvent our
> > MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
> >
> > MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> > LICENSE file applies");
>
> Hey, that is interesting in itself, since playing the above kinds of games
> makes it pretty clear to everybody that any infringement was done
> wilfully. They should be talking to their lawyers about things like that.
>
> Anyway, I suspect that rather than blacklist bad people, I'd much prefer
> to have the module tags be done as counted strings instead. It should be
> easy enough to do by just having the macro prepend a "sizeof(xxxx)"
> thing or something.
>
> Hmm. At least with -sdt=c99 it should be trivial, with something like
>
> #define __MODULE_INFO(tag, name, info) \
> static struct { int len; const char value[] } \
> __module_cat(name,__LINE__) __attribute_used__ \
> __attribute__((section(".modinfo"),unused)) = \
> { sizeof(__stringify(tag) "=" info), \
> __stringify(tag) "=" info }
>
> doing the job.
>
> That should make it pretty easy to parse the .modinfo section too.
>
> Linus
Its a joke anyway gcc3.x allows this to happen. As i posted on the
gcc mailinglist some time ago :
"Re: C Code mutilation by using gcc-3.3.x"
http://gcc.gnu.org/ml/gcc/2004-02/msg00313.html :
-------------------------------------------------
"
>
> On Feb 4, 2004, at 12:01, Robert M. Stockmann wrote:
> > Whats going on here?
>
> gcc 3.x supports C99 style of initializing of structors which was not
> supported in 2.95.3.
To be more specific about what i am complaining about, here's a
error message i get when doing ./configure inside ntfsprogs-1.8.4 :
checking version of gcc... 2.95.3, bad
configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+
version! Earlier compiler versions will NOT work as these do not support
unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
[jackson:stock]:(~/src/ntfsprogs-1.8.4)$
Aha, unnamed/annonymous structures and unions .....
Well thats briljant... in 2 years time all Open Source code will be unnamed
and anonymous in the form of propiatary .o modules, and Linus will still
be happy to deliver his /usr/src/linux/kernel subtree of the Linux
kernel source. Quite funny to see Open Source evolving by implementing
"modern" C compilers like gcc-3.x.
BTW. inside the Linux kernel source the Changes file explicitly states :
"The recommended compiler for the kernel is gcc 2.95.x (x >= 3), and it
should be used when you need absolute stability. You may use gcc 3.0.x
instead if you wish, although it may cause problems. Later versions of gcc
have not received much testing for Linux kernel compilation, and there are
almost certainly bugs (mainly, but not exclusively, in the kernel) that
will need to be fixed in order to use these compilers. In any case, using
pgcc instead of egcs or plain gcc is just asking for trouble."
-------------------------------------------------------------------------
It surely looks like the unnamed and annonymous powers of gcc-3.x finally
have reached the linux-kernel list. If you allow trash into your
gcc compilers, the resulting code and binary's are in the same
way affected.
regards,
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
Nick Warne
I don't know anything on the guru's side of coding and stuff in the
kernel, but I do know enough to say the module in question WAS coded
to give a false impression (or true, if you like) to the kernel so
that it supressed the 'tainted' kernel warnings.
But surely in an open source project [any project], tainted code
needs to be highlighted? What else is in there, or not? A GNU/Linux
platform needs to be told when a unknown and unvetted binary loads -
who can prove what it does otherwise, and therefore the onus is on
the user?
Maybe binary suppliers need to speak to kernel crew first on what
they need to do to get around these issues legally before it is
'discovered' and appears to be an attempt get around safeguards in
place.
Nick
--
"When you're chewing on life's gristle,
Don't grumble, Give a whistle..."
Robert M. Stockmann
> "Robert M. Stockmann" <st...@stokkie.net> writes:
>
> [snip]
> > To be more specific about what i am complaining about, here's a
> > error message i get when doing ./configure inside ntfsprogs-1.8.4 :
> >
> > checking version of gcc... 2.95.3, bad
> > configure: error: Please upgrade your gcc compiler to gcc-2.96+ or gcc-3+
> > version! Earlier compiler versions will NOT work as these do not support
> > unnamed/annonymous structures and unions which are used heavily in linux-ntfs.
> > [jackson:stock]:(~/src/ntfsprogs-1.8.4)$
> >
> > Aha, unnamed/annonymous structures and unions .....
>
> Please keep rants about applications' coding style where they belong:
> off the linux-kernel list. If you bothered to READ what Linus wrote,
> you would see that the structure being defined has a name -- in fact,
> gcc requires that, since the structure would be defined at file scope
> rather than inside another structure or union.
>
> Michael
Hi Michael,
look i have made complaints about gcc-3.x some time ago, on the gcc
mailinglist. Also there they put my opinions aside, with arguments
like any powerfull feature can be used in a bad and in a good way.
The powerfull feature here is the C99 coding style, which allows for
unnamed and anonymous structures and unions. Don't kill our C99 cause it
can do bad things. Of course not.
However when dealing with OEM hardware vendors, which have signed contracts
with Microsoft about windows drivers, i think we cannot allow these same
OEM hardware vendors to introduce binary only drivers of unknown quality into
the linux kernel. Its exactly these events which give the Linux kernel, or
even Linux in general, give a bad reputation. Think about rants like this :
"The Promise FastTrak TX4000 IDE-RAID controller works perfect inside Windows,
but inside Linux i even lost my data."
The Promise Fasttrak issue i discussed here :
http://gcc.gnu.org/ml/gcc/2004-02/msg00293.html
If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
its policy, to implement its drivers as semi- binary only kernel modules, like
Promise did with its FastTrak line of controllers, like in the example above,
the Open Source lable of the linux kernel can be placed into the computer
museum. Isn't that exactly what a certain Redmond software company wants
to achieve?
Cheers,
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
Tim Hockin
> look i have made complaints about gcc-3.x some time ago, on the gcc
> mailinglist. Also there they put my opinions aside, with arguments
> like any powerfull feature can be used in a bad and in a good way.
> The powerfull feature here is the C99 coding style, which allows for
> unnamed and anonymous structures and unions. Don't kill our C99 cause it
> can do bad things. Of course not.
> If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> its policy, to implement its drivers as semi- binary only kernel modules, like
> Promise did with its FastTrak line of controllers, like in the example above,
> the Open Source lable of the linux kernel can be placed into the computer
> museum. Isn't that exactly what a certain Redmond software company wants
> to achieve?
What the hell do these two paragraphs have to do with each other?
Rusty Russell
> Actually, we also have no desire nor purpose to prevent tainting. The purpose
> of the workaround is to avoid repetitive warning messages generated when
> multiple modules belonging to a single logical "driver" are loaded (even when
> a module is only probed but not used due to the hardware not being present).
You lied about the license, rather than submit a one-line change to
kernel/module.c.
This shows a lack of integrity that I find personally repulsive.
Name: Only Print Taint Message Once
Status: Trivial
Only print the tainted message the first time. Its purpose is to warn
users that we can't support them, not to fill their logs.
diff -urpN --exclude TAGS -X /home/rusty/devel/kernel/kernel-patches/current-dontdiff --minimal .22310-linux-2.6.6-rc2-bk5/kernel/module.c .22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c
--- .22310-linux-2.6.6-rc2-bk5/kernel/module.c 2004-04-22 08:04:00.000000000 +1000
+++ .22310-linux-2.6.6-rc2-bk5.updated/kernel/module.c 2004-04-28 09:03:31.000000000 +1000
@@ -1131,7 +1131,7 @@ static void set_license(struct module *m
license = "unspecified";
mod->license_gplok = license_is_gpl_compatible(license);
- if (!mod->license_gplok) {
+ if (!mod->license_gplok && !(tainted & TAINT_PROPRIETARY_MODULE)) {
printk(KERN_WARNING "%s: module license '%s' taints kernel.\n",
mod->name, license);
tainted |= TAINT_PROPRIETARY_MODULE;
--
Anyone who quotes me in their signature is an idiot -- Rusty Russell
Carl-Daniel Hailfinger
> Hi everyone,
>
> On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
>
>>Hi,
>>
>>LinuxAnt offers binary only modules without any sources.
>
>
> code.
As somebody else already asked: Where is that source?
>>To circumvent our
>>MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
>>
>>MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
>>LICENSE file applies");
>
>
>
> Paulo Marques said:
>
>>The way I see it, they know a C string ends with a '\0'. This is like saying
>>that a English sentence ends with a dot. If they wrote "GPL\0" they are
>>effectively saying that the license *is* GPL period.
>>
>>So, where the source code? :)
>
>
> Unfortunately Linuxant cannot release the source for the proprietary portions
> [...]
Then why do you claim the license of the proprietary portions is GPL?
> Willy Tarreau <willy () w ! ods ! org> wrote:
>
>> [...]
>>
>>>The attached patch blacklists all modules having "Linuxant" or "Conexant"
>>>in their author string. This may seem a bit broad, but AFAIK both
>>>companies never have released anything under the GPL and have a strong
>>>history of binary-only modules.
>>
>>What would be smarter would be to try to understand why they do this.
>
> Exactly. Linuxant's intent is NOT to circumvent any license checks (see
> below for why this specific workaround was put in) which would be unnecessary
> since the drivers in question do not use any GPL_ONLY functions, as far as
> I know.
As far as you know. Can we assume you didn't bother to check?
>>At the moment, it seems to me that their only problem is to taint the kernel.
>
>
> Actually, we also have no desire nor purpose to prevent tainting. The purpose
Then why the fuck did you prevent tainting this way?
> of the workaround is to avoid repetitive warning messages generated when
> multiple modules belonging to a single logical "driver" are loaded (even when
> a module is only probed but not used due to the hardware not being present).
> Although the issue may sound trivial/harmless to people on the lkml, it was a
> frequent cause of confusion for the average person.
"Repetitive messages". The way you did it, there are no messages at all.
If you had wanted to avoid repetitive messages, you could have
- asked on linux-kernel to not output further warnings if the kernel is
already tainted
- given at least one module a non-GPL MODULE_LICENSE.
So you are nothing but a liar caught red-handed. And such a bad liar at that.
> Other Linuxant drivers (like DriverLoader and Riptide) do not need nor use this
> workaround because they are not composed of multiple modules and one set of
> warning messages is usually bearable.
>
>
>>Why ? I don't this that any old modutils/module-utils found in any distros
>>don't load properly such modules. So perhaps they only want not to taint
>>the kernel because it appears dirty to their customers who will not receive
>>any more support from LKML. So perhaps what we really need is to add a new
>>MODULE_SUPPORT field stating where to get support from in case of bugs,
>>oopses or panics on a tainted kernel. Thus, the module author would be able
>>to insert something such as "suppo...@author.com" which will be displayed
>>on each oops/panic/etc... Even if this is a long list because the customer
>>uses connexant, nvidia, checkpoint and I don't know what, at least he will
>>get 3 email addresses for his support. And it might reassure these authors
>>to know that the customer will ask them before asking us with our automatic
>>replies "unload your binary modules...".
>
>
> Linuxant would very much welcome such steps to improve the current situation,
> and is willing to eliminate workarounds once they are no longer necessary.
Let me translate that.
"Linuxant has willfully screwed kernel developers. If they want Linuxant
to stop, they first have to do the following things: [long list]"
Since your modules are out there, we need a way to mark them as
proprietary. My patch did exactly that and nothing else.
Carl-Daniel
--
http://www.hailfinger.org/
Robert M. Stockmann
> On Wed, Apr 28, 2004 at 12:59:23AM +0200, Robert M. Stockmann wrote:
> > look i have made complaints about gcc-3.x some time ago, on the gcc
> > mailinglist. Also there they put my opinions aside, with arguments
> > like any powerfull feature can be used in a bad and in a good way.
> > The powerfull feature here is the C99 coding style, which allows for
> > unnamed and anonymous structures and unions. Don't kill our C99 cause it
> > can do bad things. Of course not.
>
> > If every major hardware vendor (like e.g. Adaptec, LSI Logic) will change
> > its policy, to implement its drivers as semi- binary only kernel modules, like
> > Promise did with its FastTrak line of controllers, like in the example above,
> > the Open Source lable of the linux kernel can be placed into the computer
> > museum. Isn't that exactly what a certain Redmond software company wants
> > to achieve?
>
> What the hell do these two paragraphs have to do with each other?
>
C99 coding style, more specific the use of unnamed and anonymous structures
and unions, allows the kernel programmer to interface, read glue, binary only
driver modules to interface with any linux kernel source tree.
Using this feature one can link and merge any binary only module.o to any
kernel source version of your choice. In this way, typically, a OEM vendor,
releases a semi open-source link kit, which also contains binary only
components, once. This semi open source link-kit will then work with any 2.6.x
or 2.4.2x kernel source tree.
The needed header files, which need to be read by the gcc compiler, contain
unnamed and annonymizes structures and unions. In the worst case scenario,
only the name of used variables are given and no info about variable type or
size are inside these headers files. gcc-2.95.3 fails to succesfully link these
semi open-source link-kits, and gcc-3.x (which supports C99) of course has
no problems doing this.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
Tim Hockin
> > What the hell do these two paragraphs have to do with each other?
>
> C99 coding style, more specific the use of unnamed and anonymous structures
> and unions, allows the kernel programmer to interface, read glue, binary only
> driver modules to interface with any linux kernel source tree.
What the hell are you going on about? Unnamed structures are a
syntactical construct and have ZILCH to do with runtime.
> The needed header files, which need to be read by the gcc compiler, contain
> unnamed and annonymizes structures and unions. In the worst case scenario,
> only the name of used variables are given and no info about variable type or
> size are inside these headers files. gcc-2.95.3 fails to succesfully link these
Opaque types have been available FOREVER.
Robert M. Stockmann
> On Wed, Apr 28, 2004 at 01:30:58AM +0200, Robert M. Stockmann wrote:
> > > What the hell do these two paragraphs have to do with each other?
> >
> > C99 coding style, more specific the use of unnamed and anonymous structures
> > and unions, allows the kernel programmer to interface, read glue, binary only
> > driver modules to interface with any linux kernel source tree.
>
> What the hell are you going on about? Unnamed structures are a
> syntactical construct and have ZILCH to do with runtime.
I thought so too, until your semi open-source link kit is linked to that
brand-new linux kernel source tree, and at the same time the binary
components of your link-kit have become incompatible with that newer kernel.
Result? one might even loose its data, upon booting that newly build
kernel and modules, in case your storage-controller has a binary only
link-kit as its driver.
> > The needed header files, which need to be read by the gcc compiler, contain
> > unnamed and annonymizes structures and unions. In the worst case scenario,
> > only the name of used variables are given and no info about variable type or
> > size are inside these headers files. gcc-2.95.3 fails to succesfully link these
>
> Opaque types have been available FOREVER.
sure, but can one qualify that as Open Source?
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
Marc Boucher
Rusty, the workaround was done a while ago, back in the 2.5 days when
your new module code
was still very much in flux. It was necessary to have an effective
short-term solution for the existing
installed base (2.4), since we could not continue to confuse customers
while waiting for the patch
to propagate. In other cases, we have gladly submitted patches when we
encountered bugs and
could fix them. Had we known that the module fix was so simple, it
would of course have been
submitted it to you in parallel.
Also since you and I have worked well together in other projects
(netfilter core) and are long time friends,
I don't understand why you are so quick to question my integrity in
public. We didn't lie about anything;
the license text is perfectly clear, and the political situation with
Conexant's proprietary signal processing
code outside of our control.
Marc
--
Marc Boucher
Linuxant inc.
Carl-Daniel Hailfinger
> Marc Boucher wrote:
>
>> On Apr 27, 2004, at 1:46 PM, Chris Friesen wrote:
>
>
>>> Does your company honestly feel that misleading the module loading
>>> tools is actually the proper way to work around the issue of
>>> repetitive warning messages? This is blatently misleading and does
>>> not reflect well, especially when the "GPL" directory mentioned in
>>> the source string is actually empty.
>>
>> It is a purely technical workaround. There is nothing misleading to
>> the human eye,
>
> modinfo reports a GPL license, and the kernel does not report itself as
> tainted. That's misleading.
The "nothing misleading to the human eye" argument is totally bogus. The
human eye does not see your sources (especially not the sources of the
completely proprietary modules).
"Marc Boucher is a sl^Hick funny d^H^H^H^H^Huck."
Is the above sentence insulting or not?
"But your honor, there is nothing misleading to the human eye. Calling
somebody a slick funny duck may seem strange, but it is surely not an insult!"
>> and the GPL directory isn't empty; it is included in full in our
>> generic .tar.gz, rpm and
>> .deb packages.
>
> My apologies. I was going on the word of the original poster.
No need to apologize. If you want to check for yourself, you'll see that
at least the SUSE .rpm packages do NOT contain any source. If you are
interested, I can send you the (signed by Linuxant) .rpm package I am
talking about.
Regards,
Carl-Daniel
--
http://www.hailfinger.org/
Robert M. Stockmann
> On Wed, Apr 28, 2004 at 01:59:08AM +0200, Robert M. Stockmann wrote:
> > > What the hell are you going on about? Unnamed structures are a
> > > syntactical construct and have ZILCH to do with runtime.
> >
> > I thought so too, until your semi open-source link kit is linked to that
> > brand-new linux kernel source tree, and at the same time the binary
> > components of your link-kit have become incompatible with that newer kernel.
>
> This is possible with any structure, named or unnamed. It's called an
> ABI, and it's one of the reasons that binary modules suck. It doesn't
> have *anything* to do with unnamed structures. At all. And if you think
> so, show me code.
here's a example :
http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip
>
> > > Opaque types have been available FOREVER.
> >
> > sure, but can one qualify that as Open Source?
>
> If used properly (and they are used in Linux, I believe) they can be very
> handy. It's a non-sequiter. no coding technique, no matter how
> incoherent, is incompatible with open source.
Opaque types should be no problem. However the complete definition must reside
somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
It summarizes code to only reflect what is essential, instead of repeating
tedious and long struct types and defines. However if Opaque types are used
inside a partial_source tree, where the complete definition is hidden
inside the binary only closed source parts, then its the complete opposite
of what i would call a bless.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
David Gibson
>
> Rusty, the workaround was done a while ago, back in the 2.5 days
> when your new module code was still very much in flux. It was
> necessary to have an effective short-term solution for the existing
> installed base (2.4), since we could not continue to confuse
> customers while waiting for the patch to propagate. In other cases,
> we have gladly submitted patches when we encountered bugs and could
> fix them. Had we known that the module fix was so simple, it would
> of course have been submitted it to you in parallel.
No, it wasn't *necessary*: you made a choice that not confusing your
customers was more important to you than not increasing the support
burden on kernel developers by releasing a silently tainted module
into the wild.
That might make sense from your business perspective, but you must
accept its consequences: anger from those you've inconvenienced for
your benefit. There's no reason they should give a fuck if your
customers are confused or not.
> Also since you and I have worked well together in other projects
> (netfilter core) and are long time friends, I don't understand why
> you are so quick to question my integrity in public. We didn't lie
> about anything; the license text is perfectly clear,
No, it's only clear if someone looks at the module's source (what's
available of it), in which case the license would presumably be clear
from comments or documentation anyway. The main purpose of the
MODULE_LICENSE() macro is to label the *module binary* with the
license. To the standard tools that look at it there, it says "GPL"
which is clearly misleading.
>and the
> political situation with Conexant's proprietary signal processing
> code outside of our control.
--
David Gibson | For every complex problem there is a
david AT gibson.dropbear.id.au | solution which is simple, neat and
| wrong.
http://www.ozlabs.org/people/dgibson
Robert M. Stockmann
> On Wed, Apr 28, 2004 at 02:18:59AM +0200, Robert M. Stockmann wrote:
> > > This is possible with any structure, named or unnamed. It's called an
> > > ABI, and it's one of the reasons that binary modules suck. It doesn't
> > > have *anything* to do with unnamed structures. At all. And if you think
> > > so, show me code.
> >
> > here's a example :
> >
> > http://www.promise.com/support/file/driver/1_fasttrak_tx4000_partial_source_1.00.0.19.zip
>
> Care to show me where they use unnamed structures, and how it has anything
> to do with binary modules?
fasttrak.h :
/*********************************************************************
fasttrak.h -- PROMISE FastTrak Controllers device driver for Linux.
Copyright (C) 2002-2005 PROMISE Technology, Inc.
This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; version 2 of the License.
Bugs/Comments/Suggestions should be mailed to:
sup...@promise.com.tw
For more information, goto:
http://www.promise.com
*********************************************************************/
#ifndef _ft3xx_h
#define _ft3xx_h
#include <linux/version.h>
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx { \
next: NULL, \
proc_dir: NULL, \
proc_info: NULL, \
name: "ft3xx", \
detect: ft3xx_detect, \
release: ft3xx_release, \
ioctl: ft3xx_ioctl, \
info: NULL, \
command: NULL, \
queuecommand: ft3xx_queuecommand, \
eh_abort_handler : ft3xx_abort_eh, \
eh_device_reset_handler : ft3xx_reset_eh, \
abort: ft3xx_abort, \
reset: ft3xx_reset, \
slave_attach: NULL, \
bios_param: ft3xx_bios_param, \
can_queue: Can_Queue, /* max simultaneous cmds */\
this_id: 7, /* scsi id of host adapter */\
sg_tablesize: Max_SG_Table - 2,/* max scatter-gather cmds */\
cmd_per_lun: 1, /* cmds per lun (linked cmds) */\
present: 0, \
unchecked_isa_dma: 0, /* no memory DMA restrictions */\
use_clustering: 0, \
use_new_eh_code: 0, /* enable this field next time*/\
emulated: 0, \
proc_name: "ft3xx" \
}
#else
#define ft3xx { \
next: NULL, \
proc_dir: NULL, \
proc_info: NULL, \
name: "ft3xx", \
detect: ft3xx_detect, \
release: ft3xx_release, \
ioctl: ft3xx_ioctl, \
info: NULL, \
command: NULL, \
queuecommand: ft3xx_queuecommand, \
eh_abort_handler : ft3xx_abort_eh, \
eh_device_reset_handler : ft3xx_reset_eh, \
abort: ft3xx_abort, \
reset: ft3xx_reset, \
slave_attach: NULL, \
bios_param: ft3xx_bios_param, \
can_queue: Can_Queue, /* max simultaneous cmds */\
this_id: 7, /* scsi id of host adapter */\
sg_tablesize: Max_SG_Table - 2, /* max scatter-gather cmds */\
cmd_per_lun: 1, /* cmds per lun (linked cmds) */\
present: 0, \
unchecked_isa_dma: 0, /* no memory DMA restrictions */\
use_clustering: 0, \
use_new_eh_code: 0, /* enable this field next time*/\
emulated: 0, \
}
#endif
#endif /* _ft3xx_h */
This header file is needed to be able to link ft3xx.o . In which way binary
incompatibility is introduced, inside this case is hard to tell. We
will never know i guess , since the type and size of the above components
is hidden inside the binary only part :
-rw-r--r-- 1 stock stock 227757 Oct 13 2003 ftlib.o
Well it works, with gcc-3.x, but not with gcc-2.95.3
>
> > Opaque types should be no problem. However the complete definition must reside
> > somewhere _inside_ the complete source. Opaque types is even a bless, i agree.
>
> If you're open, then yes. If you're not open, you could have the
> definition of the opaque type inside your own closed code, and things will
> still work. In fact, that's the sane way to do closed structures.
>
Hardware which uses these things inside its linux drivers, is hardware
i would never run Linux on.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
Marc Boucher
Hi David,
On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
> On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
>>
>> Rusty, the workaround was done a while ago, back in the 2.5 days
>> when your new module code was still very much in flux. It was
>> necessary to have an effective short-term solution for the existing
>> installed base (2.4), since we could not continue to confuse
>> customers while waiting for the patch to propagate. In other cases,
>> we have gladly submitted patches when we encountered bugs and could
>> fix them. Had we known that the module fix was so simple, it would
>> of course have been submitted it to you in parallel.
>
> No, it wasn't *necessary*: you made a choice that not confusing your
> customers was more important to you than not increasing the support
> burden on kernel developers by releasing a silently tainted module
> into the wild.
In an enterprise, customers always come first. Nonetheless, I don't
believe that this issue had a significant impact on kernel developers.
Had their support burden been significantly increased by our products,
the issue would have come up much sooner.
>
> That might make sense from your business perspective, but you must
> accept its consequences: anger from those you've inconvenienced for
> your benefit. There's no reason they should give a fuck if your
> customers are confused or not.
It's not only "my" customers, but more importantly Linux users at large.
Conexant modem chipsets are extremely common hardware devices
that need to be properly supported within the constraints that we are
facing.
Futile attempts to perform license checks generating redundant and
confusing errors, restricting access to kernel APIs for religious
reasons,
and the general lack of stable APIs and pragmatic understanding for the
needs of third-party driver suppliers result in much greater everyday
inconveniences to ordinary users and are more damaging to the
acceptance
of linux than the theoretical inconvenience our workaround might have
caused to kernel developers.
>
>> Also since you and I have worked well together in other projects
>> (netfilter core) and are long time friends, I don't understand why
>> you are so quick to question my integrity in public. We didn't lie
>> about anything; the license text is perfectly clear,
>
> No, it's only clear if someone looks at the module's source (what's
> available of it), in which case the license would presumably be clear
> from comments or documentation anyway. The main purpose of the
> MODULE_LICENSE() macro is to label the *module binary* with the
> license. To the standard tools that look at it there, it says "GPL"
> which is clearly misleading.
No need to even look at the source; this information is clearly
provided in the
LICENSE (which is also displayed on our website before downloading),
in the README file, and possibly other places too.
If the "standard tools" were more properly designed, such workarounds
would be totally unnecessary, and we would much rather avoid them.
Cordially
Marc
Robert M. Stockmann
> On Wed, Apr 28, 2004 at 02:56:16AM +0200, Robert M. Stockmann wrote:
> > > Care to show me where they use unnamed structures, and how it has anything
> > > to do with binary modules?
> >
> > fasttrak.h :
> > #define ft3xx { \
> > next: NULL, \
> ...
> > }
> > #endif
>
> > This header file is needed to be able to link ft3xx.o . In which way binary
> > incompatibility is introduced, inside this case is hard to tell. We
> > will never know i guess , since the type and size of the above components
> > is hidden inside the binary only part :
>
> Do you know C, or just pretend to?
I am no kernel coder, if its that what you mean.
>
> Those are structure initializers, not unnamed types. They've provided a
> macro to use to initialize instances of some structure.
>
> fasttrak.c:890 shows
> static Scsi_Host_Template driver_template = ft3xx;
>
> The structure definition for 'Scsi_Host_Template' is in
> /usr/src/linux/drivers/scsi/hosts.h which is included in fasttrak.c.
Ok you got me there. I would suggest to change fasttrak.h like this
to obtain better readability :
#ifndef _ft3xx_h
#define _ft3xx_h
#include <linux/version.h>
#include "/usr/src/linux/drivers/scsi/hosts.h"
#if LINUX_VERSION_CODE >= KERNEL_VERSION(2,4,0)
#define ft3xx { \
next: NULL, \
...
};
>
> If you run it thru the preprocessor, you'd see
> static Scsi_Host_Template driver_template = {
> next: NULL,
> ...
> };
>
> No opaque structs. No unnamed types. No magic. It's not pretty, and
> it's bound to break on any non-standard rig, but it's NOT what you claim
> it is.
>
> The initializer style (foo: value) is probably why gcc-2.95 blows up, but
> I don't have it here to verify.
It does, which awakened me all up in arms. certainly if gcc-2.95.3
is still mentioned as recommended gcc version for the ia32 platform
inside /usr/src/linux/Documentation/Changes. It pissed me off not
being able to use gcc-2.95.3 when using that fasttrak driver.
>
> You really should know what you're talking about before you launch a
> crusade against something.
>
I agree the fasttrak partial-source kit is not the all defining example.
Still i believe nasty stuff is possible.
Robert
--
Robert M. Stockmann - RHCE
Network Engineer - UNIX/Linux Specialist
crashrecovery.org st...@stokkie.net
-
Rusty Russell
> In other cases, we have gladly submitted patches when we
> encountered bugs and
> could fix them. Had we known that the module fix was so simple, it
> would of course have been
> submitted it to you in parallel.
Let me spell it out.
You deceived users by circumventing a check designed to tell them that
their kernel was tainted. You deceived maintainers who receive
"untainted" bug reports. In a way, you lied directly to the kernel
community: the module code is our agent in checking module licenses.
That you've been doing it for a while, or that you didn't spend
significant time investigating alternatives or talking to the maintainer
about your problem only compounds the damage. That I know and like you
only heightens my disappointment.
Hence I stand by my original comment:
This shows a lack of integrity that I find personally repulsive.
Hope that clarifies,
Rusty.
Marc Boucher
Dear Rusty,
We generally prefer to focus on making stuff work for users,
rather than waste time arguing about controversial GPL politics.
That's why after the practical workaround was done we moved on
to deal with more acute technical issues at the time and failed
to properly discuss/follow up on the matter with you. Please accept my
sincere personal apology for this.
I would like however to point out that part of the reason why people
sometimes resort to such kludges is that some kernel maintainers have
been rather reluctant to accommodate proprietary drivers which
unfortunately are a necessary real-world evil (Linus told me just a few
days ago that he didn't care and to "go away" after we requested a clean
solution to handle larger kernel stacks for "foreign" NDIS drivers in a
way
that could perhaps coexist with the new 4K stacks used by default in
recent 2.6.6/fedora kernels).
Anyway, in an effort to reasonably resolve the \0 issue, to (hopefully)
mutual
satisfaction I propose that we update our drivers to explicitly set the
tainted
bit manually after they are loaded - perhaps via sysctl() or by running
"echo 1 > /proc/sys/kernel/tainted" via {modules,modprobe}.conf,
or simply changing the '\0' to ' ' in one of the modules'
MODULE_LICENSE()
macro, causing the kernel to be tainted upon load and the confusing
messages
to appear once instead of 5-6 times in a row. The latter approach seems
simple and straightforward. Would it be acceptable to you as a
compromise until
your patch and hopefully something equivalent for 2.4 propagate to
users?
Regards
Marc
--
Marc Boucher
Linuxant inc.
Horst von Brand
> On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
> > On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
> >> Rusty, the workaround was done a while ago, back in the 2.5 days
> >> when your new module code was still very much in flux. It was
> >> necessary to have an effective short-term solution for the existing
> >> installed base (2.4), since we could not continue to confuse
> >> we have gladly submitted patches when we encountered bugs and could
> >> fix them. Had we known that the module fix was so simple, it would
> >> of course have been submitted it to you in parallel.
> > No, it wasn't *necessary*: you made a choice that not confusing your
> > customers was more important to you than not increasing the support
> > burden on kernel developers by releasing a silently tainted module
> > into the wild.
> In an enterprise, customers always come first. Nonetheless, I don't
> believe that this issue had a significant impact on kernel developers.
You have absolutely no right to place _any_ burden at all on kernel
hackers. "I don't believe..." just doesn't cut it.
[...]
> Futile attempts to perform license checks generating redundant and
> confusing errors, restricting access to kernel APIs for religious
> reasons,
So? It is not _your_ call to decide under what conditions (if any) you are
allowed to use said APIs. You did not comply with the conditions as stated.
Nothing more to be said about it, you admitted so yourself.
> and the general lack of stable APIs and pragmatic understanding for the
> needs of third-party driver suppliers result in much greater everyday
> inconveniences to ordinary users and are more damaging to the
> acceptance
Third-party driver suppliers are welcome to work _with_ the kernel
community, who will in many cases happily fix their drivers as a matter of
course when updating the kernel. As long as source is available, that
is. If not, hackers don't want to spend time for _others_ to be able to
reap benefits. Go read the GPL, and then think hard about why Linux hackers
elected the GPL as the license for the kernel.
> of linux than the theoretical inconvenience our workaround might have
> caused to kernel developers.
There is a very down-to-earth inconvenience called "license violation"
here. You got a license to use the kernel API under certain conditions, you
violated those.
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Horst von Brand
> On Tue, Apr 27, 2004 at 04:09:36AM +0200, Carl-Daniel Hailfinger wrote:
> > Hi,
> > LinuxAnt offers binary only modules without any sources.
> Not true. Linuxant modules come with full source for operating-system
> specific code.
If they don't distribute _all_ source, it is not distribution under GPL.
Marc Boucher
On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:
> Marc Boucher <ma...@linuxant.com> said:
>> On Apr 27, 2004, at 8:25 PM, David Gibson wrote:
>>> On Tue, Apr 27, 2004 at 08:02:03PM -0400, Marc Boucher wrote:
>>>> Rusty, the workaround was done a while ago, back in the 2.5 days
>>>> when your new module code was still very much in flux. It was
>>>> necessary to have an effective short-term solution for the existing
>>>> installed base (2.4), since we could not continue to confuse
>>>> customers while waiting for the patch to propagate. In other cases,
>>>> we have gladly submitted patches when we encountered bugs and could
>>>> fix them. Had we known that the module fix was so simple, it would
>>>> of course have been submitted it to you in parallel.
>
>>> No, it wasn't *necessary*: you made a choice that not confusing your
>>> customers was more important to you than not increasing the support
>>> burden on kernel developers by releasing a silently tainted module
>>> into the wild.
>
>> In an enterprise, customers always come first. Nonetheless, I don't
>> believe that this issue had a significant impact on kernel developers.
>
> You have absolutely no right to place _any_ burden at all on kernel
> hackers. "I don't believe..." just doesn't cut it.
I stated a personal opinion based on the observation that the issue was
raised
in a politically provocative way. It didn't come up because specific
kernel
developers were having a hard time debugging systems with our drivers.
People should understand that we are really trying to help Linux by
providing
alternative support and drivers for proprietary hardware that
otherwise cannot
be easily handled in the traditional free-software ways, otherwise they
would
already have been implemented long ago by one of the many talented
linux kernel
hackers out there.
Folks who do not agree with the freedom of choice we are providing can
simply
avoid purchasing hardware without 100% open-source drivers, instead of
launching political attacks based on incorrect facts or behaving like a
wild mob
using intimidation practices (someone posted my personal physical
address
on Slashdot today).
>
> [...]
>
>> Futile attempts to perform license checks generating redundant and
>> confusing errors, restricting access to kernel APIs for religious
>> reasons,
>
> So? It is not _your_ call to decide under what conditions (if any) you
> are
> allowed to use said APIs. You did not comply with the conditions as
> stated.
> Nothing more to be said about it, you admitted so yourself.
AFAIK, no GPLONLY APIs are involved. The workaround is for a confusing
cosmetic issue that has been acknowledged by kernel developers and is
being fixed. I have also sent Rusty a proposal for a technical change
in our
modem drivers that would restore tainting (again, there was never any
intent,
motivation nor purpose to bypass that) while keeping the volume of
messages
under control.
>
>> and the general lack of stable APIs and pragmatic understanding for
>> the
>> needs of third-party driver suppliers result in much greater everyday
>> inconveniences to ordinary users and are more damaging to the
>> acceptance
>
> Third-party driver suppliers are welcome to work _with_ the kernel
> community, who will in many cases happily fix their drivers as a
> matter of
> course when updating the kernel. As long as source is available, that
> is. If not, hackers don't want to spend time for _others_ to be able to
> reap benefits. Go read the GPL, and then think hard about why Linux
> hackers
> elected the GPL as the license for the kernel.
We have not asked for nor expected the kernel community to fix the
proprietary
parts of, for the sake of example, the Conexant softmodem drivers,
which is not
an easy task to do just from a practical point of view since it often
requires
expensive test equipment and specialized DSP knowledge to work on
effectively.
However the portions of our products that specifically relate to the
linux kernel are
provided in source form and generally accessible to the community.
>
>> of linux than the theoretical inconvenience our workaround might have
>> caused to kernel developers.
>
> There is a very down-to-earth inconvenience called "license violation"
> here. You got a license to use the kernel API under certain
> conditions, you
> violated those.
There is a very down-to-earth tendency on the part of some people to
play
lawyer on the net and make unsubstantiated allegations.
Cordially
Marc
Helge Hafting
> On Tue, 27 Apr 2004 19:53:39 +0200, Grzegorz Kulewski said:
>
>
>>Maybe kernel should display warning only once per given licence or even
>>once per boot (who needs warning about tainting tainted kernel?)
>
>
> trying to replicate a problem with an untainted kernel.
>
> Other than that, there's probably no reason to complain on a re-taint.
>
The tainting flag is in each module. Instead of trying them all
to see what taints the kernel, run "find"
over /etc/modules/<kernelversion>
to find all modules installed, and use some program
that print out the taintedness for each file. Simple, and
works even for modules that never gets loaded during normal use.
I don't know if such a program exists, but it should be trivial
to make, just paste the kernel "tainting" code into a
ordinary program.
Helge Hafting
Helge Hafting
>
> Hi Adam,
>
> On Apr 27, 2004, at 1:25 PM, Adam Jaskiewicz wrote:
>
>>
>>> Actually, we also have no desire nor purpose to prevent tainting. The
>>> purpose
>>> of the workaround is to avoid repetitive warning messages generated when
>>> multiple modules belonging to a single logical "driver" are loaded
>>> (even when
>>> a module is only probed but not used due to the hardware not being
>>> present).
>>> it was a
>>> frequent cause of confusion for the average person.
>>>
>> explaining what
>> the error messages mean, rather than working around the liscense checking
>> code? Educate the users, rather than fibbing.
>
>
> Good idea. We will try to clarify the matter in the docs for the next
> release.
> A lot of users don't read them though, so a proper fix remains necessary..
When distributing your module (with the license string fixed)
you may also distribute a kernel patch that disables the console message.
Better: you could change the logging level so the user only gets messages
in syslog and not on the console. A customer clueless enough to be confused
by the tainting message probably don't need those other console messages either.
Users with enough clue to want these messages may then turn them on again.
Helge Hafting
>
> Dear Rusty,
>
> We generally prefer to focus on making stuff work for users,
> rather than waste time arguing about controversial GPL politics.
There is no need to _argue_ about the GPL if you don't want to.
Just obey the terms. If you don't, then you're arguing.
To me, the argument above looks like "we concentrate on making
things work for our customers, not on obeying the laws."
An argument frequently used by people you probably don't want to be
compared with. You probably didn't intend it that way, but that
what it looks like for those serious about the GPL.
> That's why after the practical workaround was done we moved on
> to deal with more acute technical issues at the time and failed
> to properly discuss/follow up on the matter with you. Please accept my
> sincere personal apology for this.
>
> I would like however to point out that part of the reason why people
> sometimes resort to such kludges is that some kernel maintainers have
> been rather reluctant to accommodate proprietary drivers which
Do not be surprised that people don't want to support your driver for free.
Everything has a price. Business usually wants to be paid in money,
kernel coders tend to want payment in the form of GPL'ed code.
Not wanting to pay in code _is_ ok, but then you get to deal with any
trouble happening to any kernel running your module, because nobody
else volunteers.
> unfortunately are a necessary real-world evil (Linus told me just a few
> days ago that he didn't care and to "go away" after we requested a clean
> solution to handle larger kernel stacks for "foreign" NDIS drivers in a way
> that could perhaps coexist with the new 4K stacks used by default in
> recent 2.6.6/fedora kernels).
Well, sometimes design decisions simply doesn't go your way. There may
indeed be no way to make Linus change his mind, so of course he tells you
to go away. The same would happen if you tried to have microsoft make a
design change _they_ don't want. You are lucky in the linux case though,
kernel developers may not support your NDIS driver but you _can_ supply
your own kernel patch (or a complete kernel) with big stacks.
Right now the 4k stack is relatively new, so the patch for 8k is simple.
In the future, there will probably be bigger pages and then your
problem goes away. In the meantime you're allowed to maintain your
own patch for whatever you can't get into mainline.
>
> Anyway, in an effort to reasonably resolve the \0 issue, to (hopefully)
> mutual
> satisfaction I propose that we update our drivers to explicitly set the
> tainted
> bit manually after they are loaded - perhaps via sysctl() or by running
> "echo 1 > /proc/sys/kernel/tainted" via {modules,modprobe}.conf,
> or simply changing the '\0' to ' ' in one of the modules' MODULE_LICENSE()
> macro, causing the kernel to be tainted upon load and the confusing
> messages
> to appear once instead of 5-6 times in a row. The latter approach seems
> simple and straightforward. Would it be acceptable to you as a
> compromise until
> your patch and hopefully something equivalent for 2.4 propagate to users?
>
I believe you have to remove the \0 to operate legally (or release the
full source under the GPL for real.)
Your customer's problem is fixable though. Either by also changing the logging level
so the message doesn't go out on the console, or by patching the line
with that printk() out of your customer's kernel.
You can do this as a part of your install program. If it gets too hard, consider
supplying the customer with your own precompiled kernel.
Helge Hafting
Tom Sightler
> We generally prefer to focus on making stuff work for users,
> rather than waste time arguing about controversial GPL politics.
Well, as one of your customers (I am a paid/licensed user of your
Conexant modem drivers for my Dell D800) I am completely turned off by
this. I use a myriad of different binary drivers on various Linux
systems, things like the NVidia binary driver, EMC PowerPath, VMware
binary module, etc. EMC PowerPath compares well to your example as it
consist of multiple modules and each one spits out a message. EMC
simply used their documentation to tell the user that these messages
means that the kernel can no longer be supported by the Linux community,
however, they can be safely ignored.
> I would like however to point out that part of the reason why people
> sometimes resort to such kludges is that some kernel maintainers have
> been rather reluctant to accommodate proprietary drivers which
> unfortunately are a necessary real-world evil
In my opinion your actions also represent a real-world evil. As a user
I'm reluctant to use proprietary drivers and certainly don't expect the ones
that I am forced to used to lie about that fact and try to pretend to be GPL
when they are not. After reading this I realized that I myself have probably
reported kernel BUG's while your drivers were loaded, not realizing that my
kernel was really tainted because it didn't report that fact. Who knows how
many other users may have done the same thing?
You seem to think that acceptance of Linux is somehow more important that the
GPL. In my opinion it's exactly the opposite, acceptance and recognition of
the the importance of the GPL and the rights it gives you is more important
than the acceptance of Linux. If the "real-world" forces you to do something
that gives up those rights (loading a binary module) the kernel should definitely
make the user aware.
Later,
Tom
Marc Boucher
Hi Helge,
On Apr 28, 2004, at 7:47 AM, Helge Hafting wrote:
> Marc Boucher wrote:
>> Dear Rusty,
>> We generally prefer to focus on making stuff work for users,
>> rather than waste time arguing about controversial GPL politics.
>
> There is no need to _argue_ about the GPL if you don't want to.
> Just obey the terms. If you don't, then you're arguing.
We are not disobeying the terms nor is there anything in the GPL that
prohibits specifically our workaround. In fact, there is tons of GPL
software out there that use even more blatant/questionable techniques
to work around constraints imposed by commercial software, which
illustrates the hypocrisy of some advocates.
>
> To me, the argument above looks like "we concentrate on making
> things work for our customers, not on obeying the laws." An argument
> frequently used by people you probably don't want to be compared with.
> You probably didn't intend it that way, but that
> what it looks like for those serious about the GPL.
You can try to make it look like whatever you like but this is not what
I said.
>
>> That's why after the practical workaround was done we moved on
>> to deal with more acute technical issues at the time and failed
>> to properly discuss/follow up on the matter with you. Please accept my
>> sincere personal apology for this.
>> I would like however to point out that part of the reason why people
>> sometimes resort to such kludges is that some kernel maintainers have
>> been rather reluctant to accommodate proprietary drivers which
> Do not be surprised that people don't want to support your driver for
> free.
> Everything has a price. Business usually wants to be paid in money,
> kernel coders tend to want payment in the form of GPL'ed code.
>
> Not wanting to pay in code _is_ ok, but then you get to deal with any
> trouble happening to any kernel running your module, because nobody
> else volunteers.
We are providing code as much as possible, without expecting free
support, but are still getting flamed.
>
>> unfortunately are a necessary real-world evil (Linus told me just a
>> few
>> days ago that he didn't care and to "go away" after we requested a
>> clean
>> solution to handle larger kernel stacks for "foreign" NDIS drivers in
>> a way
>> that could perhaps coexist with the new 4K stacks used by default in
>> recent 2.6.6/fedora kernels).
>
> Well, sometimes design decisions simply doesn't go your way. There may
> indeed be no way to make Linus change his mind, so of course he tells
> you
> to go away. The same would happen if you tried to have microsoft make
> a
> design change _they_ don't want. You are lucky in the linux case
> though,
> kernel developers may not support your NDIS driver but you _can_ supply
> your own kernel patch (or a complete kernel) with big stacks.
> Right now the 4k stack is relatively new, so the patch for 8k is
> simple.
> In the future, there will probably be bigger pages and then your
> problem goes away. In the meantime you're allowed to maintain your
> own patch for whatever you can't get into mainline.
Kernel patching and recompilation is not a practical option for most
average linux users, who are unable or unwilling do it, because it is a
long and difficult procedure. We aim to provide professional products
that are straightforward to install and just work out of the box, with
standard distributions, not custom kernel patches.
Thank you for the advice. However, if you knew our customers and
understood their needs better you would realize that these are not
feasible options.
Marc
Timothy Miller
Marc Boucher wrote:
>
>
> In an enterprise, customers always come first. Nonetheless, I don't
> believe that this issue had a significant impact on kernel developers.
> Had their support burden been significantly increased by our products,
> the issue would have come up much sooner.
>
This has all deteriorated into childish bickering rather than meaningful
debate.
The problem is that Linuxant or whoever has done something which is
misleading and violates a tenet of the GPL and the module interface of
the Linux kernel.
There may be technical reasons which excuse this, but in the end,
Linuxant needs to correct their (unintentional) error and move on. In
this society, if you violate copyright and get caught, you get slammed.
You've been caught and slammed. Fortunately, no one is suing you over
it.
But spending your time arguing about it rather than making it right is
only making you look like a jerk. At this point, no one cares about
your excuses for why you did it -- excuses accepted, technical reasons
understood, we don't blame you for what you did in the PAST.
If I were in your position, I would say, "I'm sorry. I understand the
problem, and I will fix it as soon as possible." THAT would be a
professional and ethical thing to do. It's also a good way to get on
the GOOD side of the Linux community. Everyone makes mistakes; what
matters is how they DEAL with those mistakes.
Horst von Brand
> On Apr 27, 2004, at 11:23 PM, Horst von Brand wrote:
> > Marc Boucher <ma...@linuxant.com> said:
[...]
> >> In an enterprise, customers always come first. Nonetheless, I don't
> >> believe that this issue had a significant impact on kernel developers.
> > You have absolutely no right to place _any_ burden at all on kernel
> > hackers. "I don't believe..." just doesn't cut it.
> I stated a personal opinion based on the observation that the issue was
> raised in a politically provocative way. It didn't come up because
> specific kernel developers were having a hard time debugging systems with
> our drivers.
You don't _know_ that for a fact; due to the fraudulent modules perhaps
they lost untold hours trying to find out how something broke, with no hope
to find it because it was your module.
> People should understand that we are really trying to help Linux by
> providing alternative support and drivers for proprietary hardware that
> otherwise cannot be easily handled in the traditional free-software ways,
> otherwise they would already have been implemented long ago by one of the
> many talented linux kernel hackers out there.
More power to you! But when doing so _please_ do respect the wishes (and
conditions) they place on whoever does so. That is all that is being asked
from you. Not give up your firstborn, not cough up lots of dough, not sign
obnoxious NDAs, nothing.
> Folks who do not agree with the freedom of choice we are providing can
> simply avoid purchasing hardware without 100% open-source drivers,
> instead of launching political attacks based on incorrect facts or
> behaving like a wild mob using intimidation practices (someone posted my
> personal physical address on Slashdot today).
I strongly condemn such an action.
[...]
> >> Futile attempts to perform license checks generating redundant and
> >> confusing errors, restricting access to kernel APIs for religious
> >> reasons,
> > So? It is not _your_ call to decide under what conditions (if any) you
> > are allowed to use said APIs. You did not comply with the conditions
> > as stated. Nothing more to be said about it, you admitted so
> > yourself.
> AFAIK, no GPLONLY APIs are involved.
Then why fake GPL at all?
> The workaround is for a confusing
> cosmetic issue that has been acknowledged by kernel developers and is
> being fixed. I have also sent Rusty a proposal for a technical change in
> our modem drivers that would restore tainting (again, there was never any
> intent, motivation nor purpose to bypass that)
Tainting messages are there among others to warn people they are running a
non-supported configuration. Bypassing that "for cosmetic reasons" is
exactly bypassing an important reason for tainting. It also gets in the way
of kernel hackers trying to help said customers with their problems, so it
bypasses the other reason for tainting.
> while keeping the volume
> of messages under control.
You should have asked, and helped fix it (e.g., comming up with a means to
show the message once for a group of related modules, or making all modules
that don't contain binary blobs truly GPL (in the process defining
interfaces that other winmodems could use, perhaps), or whatever). "Sorry,
your door didn't open. I needed to get in, so I broke it down." won't go
down too well if it is your house they are talking about...
--
Dr. Horst H. von Brand User #22616 counter.li.org
Departamento de Informatica Fono: +56 32 654431
Universidad Tecnica Federico Santa Maria +56 32 654239
Casilla 110-V, Valparaiso, Chile Fax: +56 32 797513
Keith D Burgess Jr
Wanted to take a moment to thank you for the incredible job you and
Linuxant have done supporting the Linux community. I have been
following the threads on the lkml and must say that I am appalled at
the way you are being <personally> treated. If it were not for
Linuxant, owners of the "linux unfriendly" chipsets would be SOL. I for
one was pis**d when I found out my 2100b wireless card in my brand
spanking new X31 was not supported; until of course, I stumbled upon
driverloader. While there are other "free" alternatives out there and
also the ipw2100 project, I for one do not want to go through the
effort of compiling, modifying kernel parameters etc. For me, the $20
spent on driverloader was well worth it and allowed me to scrap XP for
Linux. And how about support? I surely appreciated the personal
support, and hours, you spent on my laptop hanging issue. Would I
recieve that from the other project's community members?
With that said, I must admit that I was one of those confused users
when I first saw the tainted kernel message(s). I have used Linux (I
repeat, <<used>> Linux) since about 96 or so. I don't claim to be an
expert or a developer but by no means am a Linux newbie. Just because I
am more interested in applications, window managers and graphical
environments such as gnome and kde, then meaningless (to the user)
kernel messages, does not make me a stupid user. However, not fully
understanding the kernel message, I thought something was wrong the
first time I noticed it (VMware modules as I recall.)
The Kernel developers should be focused on bringing Linux to the
attention of EVERY desktop user, not just those who are knowledgeable
of kernel messages, configuration, APIs and the GPL. Why do you think
that distributions such as Xandros have become so popular to users
switching to Linux? It seems rather simple to me; the product just
plain works! Is the diamond of their OS, the file manager, released
under the GPL? Of course not, and the users do not care! They just want
to be able to integrate into existing Windows environments,
authenticate against their NT/AD domains and be able to map to existing
Windows network resources - all seamlessly.
In summary, I firmly feel that there needs to be a mindset change if
Linux is to eat away at Windows market share on the desktops. Let's
take a certain Linux distributor as an example; here is a quote from a
recent posting on the 4K stacks issue:
"Too bad. External binary modules never have, and never will hold back
development. NVIDIA need to issue driver updates that work accordingly."
Reworded from a user-focused perspective:
"External binary modules shouldn't hold back development. Although
NVIDIA needs to issue driver updates that work accordingly, <>
understands that our users are the number one priority. Therefore,
until new modules are released, we will offer a workaround for users
who are effected."
Sincerely,
Keith
----------------------------------------------
Mailblocks - A Better Way to Do Email
http://about.mailblocks.com/info
Marc Boucher
On Apr 28, 2004, at 3:32 PM, Timothy Miller wrote:
>
>
> Marc Boucher wrote:
>
>>> I believe you have to remove the \0 to operate legally (or release
>>> the full source under the GPL for real.)
>>> Your customer's problem is fixable though. Either by also changing
>>> the logging level
>>> so the message doesn't go out on the console, or by patching the
>>> line with that printk() out of your customer's kernel.
>>> You can do this as a part of your install program. If it gets too
>>> hard, consider
>>> supplying the customer with your own precompiled kernel.
>> Thank you for the advice. However, if you knew our customers and
>> understood their needs better you would realize that these are not
>> feasible options.
>
>
> If your only "options" involve violating the GPL, then you cannot do
> business in this area.
that's not what I said. What I said is that kernel patches are not an
acceptable temporary workaround for the large installed base of average
customers, since they generally cannot or do not want to bother
recompiling stuff. We still make source for linux code and other parts
required to allow the technically inclined to easily rebuild the
modules and comply with the GPL.
> "Someone won't let me release some code" isn't an excuse for breaking
> the law.
>
The proprietary code that cannot be released in source form is
licensed material that was essentially developed by another party
(Conexant) for other platforms. It clearly does not constitute a
derived work of Linux.
Marc
--
Marc Boucher
Linuxant inc.
-
Timothy Miller
Marc Boucher wrote:
>
> Timothy,
>
> I am truly sorry about the concern this has caused, have already
> publicly apologized for not submitting a patch to properly correct the
> issue when the workaround was implemented, and proposed a change to the
> modem drivers that should go in as soon as possible to restore tainting
> and one instance of the warning messages while avoiding the flood.
I was not personally offended, but I hope what you said here is taken by
others as a good-faith gesture.
>
> At the same time, I think that the "community" should, without
> relinquishing its principles, be less eager before getting the facts to
> attack people and companies trying to help in good faith, and be more
> realistic when it comes to satisfying practical needs of ordinary users.
This is just part of the community, something which you should learn to
take advantage of. It's part of an impressive system of checks and
balances.
A major principle of internet communication is that people will say
venomous things in email which they would never say to you in person.
You have to take what they say for what it MEANS, not what it looks like.
If you're flamed, particularly in a forum like LKML, pay attention to
the meat of what the person is saying. If the person is right, GREAT.
If the person has completely misunderstood the situation, let it go.
And then, don't get drawn into endless debate defending yourself to
every comment that people make. Sometimes, it's best to just summarize
the situation, acknowledge people's complaints, explain which ones are
factual, and explain that you're working on a solution.
There are a number of people on LKML who seem to do an amazing job of
getting to the point in a debate. Take Theodore Ts'o, for example. In
particular, his posts are a pleasure to read because they are so clear
and full of knowledge.
Marc Boucher
Timothy,
I am truly sorry about the concern this has caused, have already
publicly apologized for not submitting a patch to properly correct the
issue when the workaround was implemented, and proposed a change to the
modem drivers that should go in as soon as possible to restore tainting
and one instance of the warning messages while avoiding the flood.
At the same time, I think that the "community" should, without
relinquishing its principles, be less eager before getting the facts to
attack people and companies trying to help in good faith, and be more
realistic when it comes to satisfying practical needs of ordinary
users.
Sincerely
Marc
--
Marc Boucher
Linuxant inc.
Timothy Miller
Marc Boucher wrote:
>> I believe you have to remove the \0 to operate legally (or release the
>> full source under the GPL for real.)
>> Your customer's problem is fixable though. Either by also changing
>> the logging level
>> so the message doesn't go out on the console, or by patching the line
>> with that printk() out of your customer's kernel.
>> You can do this as a part of your install program. If it gets too
>> hard, consider
>> supplying the customer with your own precompiled kernel.
>
>
> Thank you for the advice. However, if you knew our customers and
> understood their needs better you would realize that these are not
> feasible options.
If your only "options" involve violating the GPL, then you cannot do
business in this area. "Someone won't let me release some code" isn't
an excuse for breaking the law.
-
Pavel Machek
> > LinuxAnt offers binary only modules without any sources. To circumvent our
> > MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
> >
> > MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
> > LICENSE file applies");
>
> Hey, that is interesting in itself, since playing the above kinds of games
> makes it pretty clear to everybody that any infringement was done
> wilfully. They should be talking to their lawyers about things like that.
Even better they should be talking to our layers.
Are they trying to get access to GPL-only symbols?
--
64 bytes from 195.113.31.123: icmp_seq=28 ttl=51 time=448769.1 ms
Pavel Machek
> The way I see it, they know a C string ends with a '\0'. This is like
> saying that a English sentence ends with a dot. If they wrote "GPL\0"
> they are effectively saying that the license *is* GPL period.
If you use modinfo, license probably will be displayed as GPL.
I'd guess that sending bunch of lawyers their way is right solution.
Pavel
Marc Boucher
On Apr 28, 2004, at 10:03 AM, Tom Sightler wrote:
> On Tue, 2004-04-27 at 23:28, Marc Boucher wrote:
>> We generally prefer to focus on making stuff work for users,
>> rather than waste time arguing about controversial GPL politics.
>
> Well, as one of your customers (I am a paid/licensed user of your
> Conexant modem drivers for my Dell D800) I am completely turned off by
> this. I use a myriad of different binary drivers on various Linux
> systems, things like the NVidia binary driver, EMC PowerPath, VMware
> binary module, etc. EMC PowerPath compares well to your example as it
> consist of multiple modules and each one spits out a message. EMC
> simply used their documentation to tell the user that these messages
> means that the kernel can no longer be supported by the Linux
> community,
> however, they can be safely ignored.
I'm sorry, but the typical user of EMC PowerPath cannot really be
compared to the typical winmodem user.
If the issue hadn't been a real confusing / usability problem for
thousands of individual customers, we wouldn't have bothered with the
workaround.
>> I would like however to point out that part of the reason why people
>> sometimes resort to such kludges is that some kernel maintainers have
>> been rather reluctant to accommodate proprietary drivers which
>> unfortunately are a necessary real-world evil
>
> In my opinion your actions also represent a real-world evil. As a user
> I'm reluctant to use proprietary drivers and certainly don't expect
> the ones
> that I am forced to used to lie about that fact and try to pretend to
> be GPL
> when they are not.
It is very common practice to simulate the perception of software to
work around things and provide increased comfort and compatibility.
Entire GPL projects like wine, reactos, ndiswrapper (an open-source
clone of our DriverLoader), and even the linux kernel itself implement
foreign APIs or many workarounds to make programs or drivers function,
even believe that they are running in another environment. Do these
projects "lie" and represent real-world evils by technically pretending
/ emulating results when they are in fact not the real thing?
> After reading this I realized that I myself have probably
> reported kernel BUG's while your drivers were loaded, not realizing
> that my
> kernel was really tainted because it didn't report that fact. Who
> knows how
> many other users may have done the same thing?
The problem goes both ways. Non-standard, unreported and hard to detect
kernel patches have caused numerous users to report alleged driver bugs
to us. You wouldn't know how much time and resources these things cost
us.
> You seem to think that acceptance of Linux is somehow more important
> that the
> GPL. In my opinion it's exactly the opposite, acceptance and
> recognition of
> the the importance of the GPL and the rights it gives you is more
> important
> than the acceptance of Linux.
Some folks are more ideological than practical, but most people use
Linux to solve practical needs.
The former are a lot more vocal than the silent majority.
> If the "real-world" forces you to do something
> that gives up those rights (loading a binary module) the kernel should
> definitely
> make the user aware.
The important part here is making the user aware, which we have clearly
done.
Marc
Stephen Hemminger
Marc Boucher <ma...@linuxant.com> wrote:
lent majority.
>
> > If the "real-world" forces you to do something
> > that gives up those rights (loading a binary module) the kernel should
> > definitely
> > make the user aware.
>
> The important part here is making the user aware, which we have clearly
> done.
>
> Marc
No, the important thing is to admit when you were *wrong* and fix the problem.
But many people suffer from inability to admit a mistake (like GWB).
Timothy Miller
Pavel Machek wrote:
> Hi!
>
>
>>The way I see it, they know a C string ends with a '\0'. This is like
>>saying that a English sentence ends with a dot. If they wrote "GPL\0"
>>they are effectively saying that the license *is* GPL period.
>
>
> If you use modinfo, license probably will be displayed as GPL.
> I'd guess that sending bunch of lawyers their way is right solution.
The very fact that someone who represents the company is willing to talk
to us on LKML should be mega points in their favor.
Yes, they did something wrong, but they're giving us the time of day,
something a lot of companies don't do until the FSF has been hounding
them for a year.
Timothy Miller
Stephen Hemminger wrote:
>
>
> No, the important thing is to admit when you were *wrong* and fix the problem.
>
> But many people suffer from inability to admit a mistake (like GWB).
Marc apologized.
Rik van Riel
> The way I see it, they know a C string ends with a '\0'. This is like saying
> that a English sentence ends with a dot. If they wrote "GPL\0" they are
> effectively saying that the license *is* GPL period.
>
> So, where the source code? :)
Definitely my favorite approach of dealing with these
people. Does anybody know whether their modules use
any EXPORT_SYMBOL_GPL symbols and whether they touch
any code I could claim copyright on ?
If it touches any of my code, where should I mail the
cease & desist ? ;)
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
Rik van Riel
> In an enterprise, customers always come first.
If that were true, you wouldn't be charging anybody
any money for the product ;)
However, in real companies there are other groups
of people just as important as the customers,
including investors, employees and the copyright
holders of any code your business critically
depends on.
Tim Connors
> The Kernel developers should be focused on bringing Linux to the
> attention of EVERY desktop user, not just those who are knowledgeable
> of kernel messages, configuration, APIs and the GPL. Why do you think
Um, I don't think you presonally know why most linux kernel developers
are working. Some work to make a technically superior OS. Some work
for idealogical reasons.
I suspect not many are "focused on bringing Linux to the attention of
EVERY desktop user" because they are not interested in that. That's a
job for someone in suits. And just because you think they shoudl be
focussed on that doesn't mean they should be.
--
TimC -- http://astronomy.swin.edu.au/staff/tconnors/
Brown's Theorem (Physics III student, Usyd):
"The only thing that behaves like a billiard
ball, is a billiard ball"
Rik van Riel
> The problem goes both ways. Non-standard, unreported and hard to detect
> kernel patches have caused numerous users to report alleged driver bugs
> to us. You wouldn't know how much time and resources these things cost
> us.
The problem shouldn't be going both ways, though.
It is your decision to publish a module that taints
the kernel, so the support burden should not fall on
the kernel community...
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Rik van Riel
> At the same time, I think that the "community" should, without
> relinquishing its principles, be less eager before getting the facts to
> attack people and companies trying to help in good faith, and be more
> realistic when it comes to satisfying practical needs of ordinary
> users.
I wouldn't be averse to changing the text the kernel prints
when loading a module with an incompatible license. If the
text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
the users, it's easy enough to change it.
How about the following?
"Due to $MOD_FOO's license ($BLAH), the Linux kernel community
cannot resolve problems you may encounter. Please contact
$MODULE_VENDOR for support issues."
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Nick Piggin
> On Wed, 28 Apr 2004, Marc Boucher wrote:
>
>
>>At the same time, I think that the "community" should, without
>>relinquishing its principles, be less eager before getting the facts to
>>attack people and companies trying to help in good faith, and be more
>>realistic when it comes to satisfying practical needs of ordinary
>>users.
>
>
> I wouldn't be averse to changing the text the kernel prints
> when loading a module with an incompatible license. If the
> text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
> the users, it's easy enough to change it.
>
> How about the following?
>
> "Due to $MOD_FOO's license ($BLAH), the Linux kernel community
> cannot resolve problems you may encounter. Please contact
> $MODULE_VENDOR for support issues."
>
I think something like that is much easier to decipher.
Kenneth Aafløy
> Rik van Riel wrote:
> > On Wed, 28 Apr 2004, Marc Boucher wrote:
> >>At the same time, I think that the "community" should, without
> >>relinquishing its principles, be less eager before getting the facts to
> >>attack people and companies trying to help in good faith, and be more
> >>realistic when it comes to satisfying practical needs of ordinary
> >>users.
> >
> > I wouldn't be averse to changing the text the kernel prints
> > when loading a module with an incompatible license. If the
> > text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
> > the users, it's easy enough to change it.
> >
> > How about the following?
> >
> > "Due to $MOD_FOO's license ($BLAH), the Linux kernel community
> > cannot resolve problems you may encounter. Please contact
> > $MODULE_VENDOR for support issues."
>
> I think something like that is much easier to decipher.
Why cannot the binary module suppliers tell their customers why this 'tainted'
message is appearing in their kernel log?
You know they are human, and have a mind of their own, they would probably
have understood the fact that the company is providing it's own set of
drivers that might not be tested fully on every kernel release. And so their
customers (like what nVidias and others companies customers have done in the
past) would turn to this company for support instead of the lkml.
Kenneth
does not need to state the fact that this is just 2 cents.
Marc Boucher
Hi Rik,
Your new proposed message sounds much clearer to the ordinary mortal
and would imho be a significant improvement. Perhaps printing
repetitive warnings for identical $MODULE_VENDOR strings could also be
avoided, taking care of the redundancy/volume problem as well..
Cheers
Marc
Ian Stirling
>
> Hi Rik,
>
> Your new proposed message sounds much clearer to the ordinary mortal and
> would imho be a significant improvement. Perhaps printing repetitive
> warnings for identical $MODULE_VENDOR strings could also be avoided,
> taking care of the redundancy/volume problem as well..
Is this worth 100 or 200 bytes of code though?
I'd have to say no.
Rik van Riel
> > Your new proposed message sounds much clearer to the ordinary mortal and
> > would imho be a significant improvement. Perhaps printing repetitive
> > warnings for identical $MODULE_VENDOR strings could also be avoided,
> > taking care of the redundancy/volume problem as well..
>
> Is this worth 100 or 200 bytes of code though?
> I'd have to say no.
I suspect it'll be worth it. If only because it'll save
the kernel community from people asking things like:
"help, my kernel is tainted! what does it mean and how can I fix it?"
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Ian Stirling
> On Thu, 29 Apr 2004, Ian Stirling wrote:
>
>
>>>Your new proposed message sounds much clearer to the ordinary mortal and
>>>would imho be a significant improvement. Perhaps printing repetitive
>>>warnings for identical $MODULE_VENDOR strings could also be avoided,
>>>taking care of the redundancy/volume problem as well..
>>
>>Is this worth 100 or 200 bytes of code though?
>>I'd have to say no.
>
>
> I suspect it'll be worth it. If only because it'll save
> the kernel community from people asking things like:
>
> "help, my kernel is tainted! what does it mean and how can I fix it?"
Sorry.
I meant adding code to suppress warnings, not the expanded warning, which is sensible.
Kenneth Aafløy
> Marc Boucher wrote:
> > Hi Rik,
> >
> > Your new proposed message sounds much clearer to the ordinary mortal and
> > would imho be a significant improvement. Perhaps printing repetitive
> > warnings for identical $MODULE_VENDOR strings could also be avoided,
> > taking care of the redundancy/volume problem as well..
>
> Is this worth 100 or 200 bytes of code though?
> I'd have to say no.
1000-2000(?) instructions to display the message and some x(?) instructions to
check if it's been reported before, yeah, i'd have to say no too. ;)
Kenneth
Rick Zeman
>I wouldn't be averse to changing the text the kernel prints
>when loading a module with an incompatible license. If the
>text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
>the users, it's easy enough to change it.
>
>How about the following?
>
>"Due to $MOD_FOO's license ($BLAH), the Linux kernel community
>cannot resolve problems you may encounter. Please contact
>$MODULE_VENDOR for support issues."
That's too sensible: Linux wouldn't be Linux without incomprehensible
messages like:
$ sudo urpmi /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm
installing /home/rzeman/kernel-smp-2.4.25.4mdk-1-1mdk.i586.rpm
Preparing...
##################################################
1:kernel-smp-2.4.25.4mdk
##################################################
look like there was a problem, the default vmlinuz version is not the same
of the initrd which mean you have a mdk kernel and not a mdk initrd you may
go in trouble
or doing a menuconfig on a new 2.4.26 kernel and having it nicely tell me
that my choice HAD to be a module, not built in, because it depends upon
something else already selected as a module--without bothering to deign to
say what the dependency was so I had to play grand guessing games.
/this week's irritations.
--
Mac OS X: Because making UNIX user-friendly was easier than fixing Windows.
Timothy Miller
Rik van Riel wrote:
> On Wed, 28 Apr 2004, Marc Boucher wrote:
>
>
>>At the same time, I think that the "community" should, without
>>relinquishing its principles, be less eager before getting the facts to
>>attack people and companies trying to help in good faith, and be more
>>realistic when it comes to satisfying practical needs of ordinary
>>users.
>
>
> I wouldn't be averse to changing the text the kernel prints
> when loading a module with an incompatible license. If the
> text "$MOD_FOO: module license '$BLAH' taints kernel." upsets
> the users, it's easy enough to change it.
>
> How about the following?
>
> "Due to $MOD_FOO's license ($BLAH), the Linux kernel community
> cannot resolve problems you may encounter. Please contact
> $MODULE_VENDOR for support issues."
Sounds very "politically correct", but certainly more descriptive and
less alarming.
Rik van Riel
> > "Due to $MOD_FOO's license ($BLAH), the Linux kernel community
> > cannot resolve problems you may encounter. Please contact
> > $MODULE_VENDOR for support issues."
>
> Sounds very "politically correct", but certainly more descriptive and
> less alarming.
More importantly, it directs the support burden to where
it, IMHO, belongs.
--
"Debugging is twice as hard as writing the code in the first place.
Therefore, if you write the code as cleverly as possible, you are,
by definition, not smart enough to debug it." - Brian W. Kernighan
-
Giuliano Colla
>Hi,
>
>LinuxAnt offers binary only modules without any sources. To circumvent our
>MODULE_LICENSE checks LinuxAnt has inserted a "\0" into their declaration:
>
>MODULE_LICENSE("GPL\0for files in the \"GPL\" directory; for others, only
>LICENSE file applies");
>
>Since string comparisons stop at the first "\0" character, the kernel is
>tricked into thinking the modules are GPL. Btw, the "GPL" directory they
>are speaking about is empty.
>
>The attached patch blacklists all modules having "Linuxant" or "Conexant"
>in their author string. This may seem a bit broad, but AFAIK both
>companies never have released anything under the GPL and have a strong
>history of binary-only modules.
>
>
>Regards,
>Carl-Daniel
>
>
<snip>
Let's try not to be ridiculous, please.
As an end user, if I buy a full fledged modem, I get some amount of
proprietary, non GPL, code which executes within the board or the
PCMCIA card of the modem. The GPL driver may even support the
functionality of downloading a new version of *proprietary* code into
the flash Eprom of the device. The GPL linux driver interfaces with it,
and all is kosher.
On the other hand, I have the misfortune of being stuck with a
soft-modem, roughly the *same* proprietary code is provided as a binary
file, and a linux driver (source provided) interfaces with it. In that
case the kernel is flagged as "tainted".
But in both cases, if the driver is poorly written, because of
developer's inadequacy, or because of the proprietary code being poorly
documented and/or implemented, my kernel may go nuts, be it tainted or not.
Can you honestly tell apart the two cases, if you don't make a it a case
of "religion war"?
For sake of completeness. *My* download of
contains, in the /modules/GPL/ directory the following files:
-rw-r--r-- 1 colla colla 18860 ago 23 2003 COPYING
-rw-r--r-- 1 colla colla 13609 gen 18 00:51 oscompat.h
-rw-r--r-- 1 colla colla 32573 mar 26 09:16 serial_cnxt.c
-rw-r--r-- 1 colla colla 3392 ago 23 2003 serial_cnxt.h
-rw-r--r-- 1 colla colla 57857 ago 24 2003 serial_core.c
-rw-r--r-- 1 colla colla 9789 ago 22 2003 serial_core.h
I strongly hope that developers' efforts will be addressed to more
valuable topics than detecting the "Linuxant" string in a loadable
module. Not forgetting that Linux\0ant, L\0inuxant, etc. would display
the same way ;-)
Kind Regards
--
Ing. Giuliano Colla
Direttore Tecnico
Copeca srl
Bologna
Italy
vi...@parcelfarce.linux.theplanet.co.uk
> As an end user, if I buy a full fledged modem, I get some amount of
> proprietary, non GPL, code which executes within the board or the
> PCMCIA card of the modem. The GPL driver may even support the
> functionality of downloading a new version of *proprietary* code into
> the flash Eprom of the device. The GPL linux driver interfaces with it,
> and all is kosher.
> On the other hand, I have the misfortune of being stuck with a
> soft-modem, roughly the *same* proprietary code is provided as a binary
> file, and a linux driver (source provided) interfaces with it. In that
> case the kernel is flagged as "tainted".
>
> But in both cases, if the driver is poorly written, because of
> developer's inadequacy, or because of the proprietary code being poorly
> documented and/or implemented, my kernel may go nuts, be it tainted or not.
>
> Can you honestly tell apart the two cases, if you don't make a it a case
> of "religion war"?
Yes. *Especially* outside of religious wars - while fuckup capabilities
of Joe Random Driver Monkey are unlimited, there is a difference between
the impact of fuckups in the code that runs on CPU and in the code that
runs on peripherial. If nothing else, the latter is less likely to try
anything cute and tricky with locking.
In other words, with code running on the host CPU lusers have much, much
more ways to luse, luse again when trying to "fix" things and make it
harder to figure out what had caused the bloody mess.
Måns Rullgård
But they could make just as big a mess if they released the source
code, right? And it would be just as hard to know which driver to
blame. IF you manage to isolate the fault to one driver, it's
probably easier to see what it's doing, and possibly fix it if the
code is open. Some driver code I've seen is so messy that it doesn't
really make a difference if you have the code or not.
Don't get me wrong now. I much prefer open source drivers. Those can
be compiled on any architecture (unless stupid bugs prevent that,
which I've seen many cases of) and with the newest kernel releases.
--
Måns Rullgård
m...@kth.se
Timothy Miller
Giuliano Colla wrote:
> As an end user, if I buy a full fledged modem, I get some amount of
> proprietary, non GPL, code which executes within the board or the
> PCMCIA card of the modem. The GPL driver may even support the
> functionality of downloading a new version of *proprietary* code into
> the flash Eprom of the device. The GPL linux driver interfaces with it,
> and all is kosher.
> On the other hand, I have the misfortune of being stuck with a
> soft-modem, roughly the *same* proprietary code is provided as a binary
> file, and a linux driver (source provided) interfaces with it. In that
> case the kernel is flagged as "tainted".
>
> But in both cases, if the driver is poorly written, because of
> developer's inadequacy, or because of the proprietary code being poorly
> documented and/or implemented, my kernel may go nuts, be it tainted or not.
>
> Can you honestly tell apart the two cases, if you don't make a it a case
> of "religion war"?
>
Firmware downloaded into a piece of hardware can't corrupt the kernel in
the host.
(Unless it's a bus master which writes to random memory, which might be
possible, but there is hardware you can buy to watch PCI transactions.)
Paul Wagland
On Apr 29, 2004, at 17:14, Rik van Riel wrote:
> On Thu, 29 Apr 2004, Timothy Miller wrote:
>
>>> "Due to $MOD_FOO's license ($BLAH), the Linux kernel community
>>> cannot resolve problems you may encounter. Please contact
>>> $MODULE_VENDOR for support issues."
>>
>> Sounds very "politically correct", but certainly more descriptive and
>> less alarming.
>
> More importantly, it directs the support burden to where
> it, IMHO, belongs.
Just to throw in my two cents at the end of this long debate... :-)
I heartily endorse (for what little that is worth ;-) the change in
text. It adds clarity, it provides more information as to where to go
for information. It is hard to misconstrue as a message of impending
doom, consider that a good synonym for tainted is corrupted, and a
corrupted kernel is a bad thing :-).
Cheers,
Paul
Linus Torvalds
On Thu, 29 Apr 2004, Giuliano Colla wrote:
>
> Let's try not to be ridiculous, please.
It's not abotu being ridiculous. It's about honoring peoples copyrights.
> As an end user, if I buy a full fledged modem, I get some amount of
> proprietary, non GPL, code which executes within the board or the
> PCMCIA card of the modem. The GPL driver may even support the
> functionality of downloading a new version of *proprietary* code into
> the flash Eprom of the device. The GPL linux driver interfaces with it,
> and all is kosher.
Indeed. Everything is kosher, because the other piece of hardware and
software has _nothing_ to do with the kernel. It's not linked into it, it
cannot reasonably corrupt internal kernel data structures with random
pointer bugs, and in general you can think of firmware as part of the
_hardware_, not the software of the machine.
> On the other hand, I have the misfortune of being stuck with a
> soft-modem, roughly the *same* proprietary code is provided as a binary
> file, and a linux driver (source provided) interfaces with it. In that
> case the kernel is flagged as "tainted".
It is flagged as tainted, because your argument that it is "the same code"
is totally BOGUS AND UNTRUE!
In the binary kernel module case, a bug in the code corrupts random data
structures, or accesses kernel internals without holding the proper locks,
or does a million other things wrong, BECAUSE A KERNEL MODULE IS VERY
INTIMATELY LINKED WITH THE KERNEL.
A kernel module is _not_ a separate work, and can in _no_ way be seen as
"part of the hardware". It's very much a part of the _kernel_. And the
kernel developers require that such code be GPL'd so that it can be fixed,
or if there's a valid argument that it's not a derived work and not GPL'd,
then the kernel developers who have to support the end result mess most
definitely do need to know about the taint.
You are not the first (and sadly, you likely won't be the last) person to
equate binary kernel modules with binary firmware. And I tell you that
such a comparison is ABSOLUTE CRAPOLA. There's a damn big difference
between running firmware on another chip behind a PCI bus, and linking
into the kernel directly.
And if you don't see that difference, then you are either terminally
stupid, or you have some ulterior reason to claim that they are the same
case even though they clearly are NOT.
> Can you honestly tell apart the two cases, if you don't make a it a case
> of "religion war"?
It has absolutely nothing to do with religion.
Linus
Marc Boucher
> Can you honestly tell apart the two cases, if you don't make a it a case of
> "religion war"?
On Thu, Apr 29, 2004 at 11:15:13AM -0400, Timothy Miller answered:
>
> Firmware downloaded into a piece of hardware can't corrupt the kernel in the
> host.
>
> (Unless it's a bus master which writes to random memory, which might be
> possible, but there is hardware you can buy to watch PCI transactions.)
and unless it's a card with binary-only, proprietary BIOS code called at
runtime by the kernel, for example by the vesafb.c video driver,
which despite this has a MODULE_LICENSE("GPL").
Could someone explain why such execution of evil proprietary binary-only
code on the host CPU should not also "taint" the kernel? ;-)
Marc
Timothy Miller
While we're on all of this, are we going to change "tained" to some
other less alarmist word? Say there is a /proc file or some report that
you can generate about the kernel that simply wants to indicate that the
kernel contains closed-source modules, and we want to use a short,
concise word like "tainted" for this. "An untrusted module has been
loaded into this kernel" would be just a bit too long to qualify.
Hmmm... how about "untrusted"? Not sure...
vi...@parcelfarce.linux.theplanet.co.uk
> It has absolutely nothing to do with religion.
... and as the matter of fact, religious nuts *do* equate those two (c.f.
assorted debian-devel resident wankers)