I originally took this up with Keith Owens, but he said I should bring
the discussion here since the message was chosen here (although I could
not find where in the archives), and that he might change it if I get
the approval of Alan Cox.
I just discovered semi-recently (a couple of months ago) that newer
versions of modutils have an insmod that prints out the tainted warnings
for non-GPL licenses. While I agree that printing a warning when
installing a non-GPLed module is important to inform the user that their
kernel is no longer supported by the kernel maintainers, I have issues
with the exact message printed.
First of all, the current tainted message is not really useful.
"Warning: Loading %s will taint the kernel..." isn't very informative at
all. Most people don't know what it means to "taint the kernel". It's
a vague phrase in English, and only if you know the current kernel
source (or at least some of the semi-recent discussions on kernel
tainting) is its meaning clear. As a matter of fact, it makes it sound
like the module has a virus in it that has just infected your kernel.
As Linux becomes more common for non-experts, it becomes even more
important for error and informational messages to be clear.
Secondly, loading the module doesn't actually 'taint' the kernel, but
instead it mostly invalidates your chances for support from the core
kernel maintainers.
Thirdly, the warning that loading the module "will" taint the kernel is
an inaccurate use of tense. It implies that the module wasn't loaded
(which might be true at that time from the point of view of the code,
but is not true from the point of view of the user, which is who the
message is written for). I have actually had bug reports where users
complain that a module won't load because of the tense of this message.
I would like to propose that a clearer, more direct message be used.
Something like "Warning: kernel maintainers may not support your kernel
since you have loaded %s: %s%s\n" would be much more informative and
correct.
Opinions? Comments?
Thanks!
-- Richard Thrapp
Well a smart user could eliminate the tainted stuff and get support
anyway.
What's the point of having such a message ? I think it's trivial to get
rid of it anyway.
- Enrico
-----Original Message-----
From: [email protected]
[mailto:[email protected]] On Behalf Of Richard Thrapp
Sent: April 26, 2002 9:52 PM
To: linux-kernel; [email protected]
Subject: The tainted message
I originally took this up with Keith Owens, but he said I should bring
the discussion here since the message was chosen here (although I could
not find where in the archives), and that he might change it if I get
the approval of Alan Cox.
I just discovered semi-recently (a couple of months ago) that newer
versions of modutils have an insmod that prints out the tainted warnings
for non-GPL licenses. While I agree that printing a warning when
installing a non-GPLed module is important to inform the user that their
kernel is no longer supported by the kernel maintainers, I have issues
with the exact message printed.
First of all, the current tainted message is not really useful.
"Warning: Loading %s will taint the kernel..." isn't very informative at
all. Most people don't know what it means to "taint the kernel". It's
a vague phrase in English, and only if you know the current kernel
source (or at least some of the semi-recent discussions on kernel
tainting) is its meaning clear. As a matter of fact, it makes it sound
like the module has a virus in it that has just infected your kernel.
As Linux becomes more common for non-experts, it becomes even more
important for error and informational messages to be clear.
Secondly, loading the module doesn't actually 'taint' the kernel, but
instead it mostly invalidates your chances for support from the core
kernel maintainers.
Thirdly, the warning that loading the module "will" taint the kernel is
an inaccurate use of tense. It implies that the module wasn't loaded
(which might be true at that time from the point of view of the code,
but is not true from the point of view of the user, which is who the
message is written for). I have actually had bug reports where users
complain that a module won't load because of the tense of this message.
I would like to propose that a clearer, more direct message be used.
Something like "Warning: kernel maintainers may not support your kernel
since you have loaded %s: %s%s\n" would be much more informative and
correct.
Opinions? Comments?
Thanks!
-- Richard Thrapp
In article <1019883102.8819.48.camel@wizard> you wrote:
> Secondly, loading the module doesn't actually 'taint' the kernel, but
> instead it mostly invalidates your chances for support from the core
> kernel maintainers.
and from most if not all distros
> I would like to propose that a clearer, more direct message be used.
> Something like "Warning: kernel maintainers may not support your kernel
> since you have loaded %s: %s%s\n" would be much more informative and
> correct.
how about:
"Warning: loading non GPL kernel module. Your kernel will be
marked 'tainted'. This means kernel maintainers cannot support your kernel."
Richard Thrapp <[email protected]> :
[...]
> First of all, the current tainted message is not really useful.
> "Warning: Loading %s will taint the kernel..." isn't very informative at
> all. Most people don't know what it means to "taint the kernel". It's
Add a reference to http://www.tux.org/lkml/#s1-18. An explanation is already
there.
--
Ueimor
> First of all, the current tainted message is not really useful.
> "Warning: Loading %s will taint the kernel..." isn't very informative at
> all. Most people don't know what it means to "taint the kernel". It's
I'd agree. I wasn't aware I had any responsibility beyond helping Arjan
who implemented it. The kernel itself has no messages/policy intentionally.
> I would like to propose that a clearer, more direct message be used.
> Something like "Warning: kernel maintainers may not support your kernel
> since you have loaded %s: %s%s\n" would be much more informative and
> correct.
> Opinions? Comments?
More informative but I think too soft. It still implies we might want to
hear about it but not reply. That isnt the case.
How about
Warning: The module you have loaded (%s) does not seem to have an open
source license. Please send any kernel problem reports to the
author of this module, or duplicate them from a boot without
ever loading this module before reporting them to the community
or your Linux vendor
??
> More informative but I think too soft. It still implies we might want to
> hear about it but not reply. That isnt the case.
>
> How about
>
> Warning: The module you have loaded (%s) does not seem to have an open
> source license. Please send any kernel problem reports to the
> author of this module, or duplicate them from a boot without
> ever loading this module before reporting them to the community
> or your Linux vendor
What about:
"WARNING: You are about to leaving the american sector."?
On Sat, 2002-04-27 at 07:08, Francois Romieu wrote:
> Richard Thrapp <[email protected]> :
> [...]
> > First of all, the current tainted message is not really useful.
> > "Warning: Loading %s will taint the kernel..." isn't very informative at
> > all. Most people don't know what it means to "taint the kernel". It's
>
> Add a reference to http://www.tux.org/lkml/#s1-18. An explanation is already
> there.
That doesn't fix the problem. The message is still wrong. A reference
to an explanation only helps the people who can reach it immediately.
Linux is also used on manufacturing floors (and several other places)
where no network connections exist.
-- Richard Thrapp
On Sat, 2002-04-27 at 10:20, Alan Cox wrote:
> More informative but I think too soft. It still implies we might want to
> hear about it but not reply. That isnt the case.
>
> How about
>
> Warning: The module you have loaded (%s) does not seem to have an open
> source license. Please send any kernel problem reports to the
> author of this module, or duplicate them from a boot without
> ever loading this module before reporting them to the community
> or your Linux vendor
>
> ??
I like the wording of that. I suggest that we change the words "an open
source license" to "a GPL-compatible license" since that's what we're
checking for (if I remember incorrectly, please correct me). It might
also be important to put the license string in there somewhere.
-- Richard Thrapp
Alan Cox wrote:
> > I would like to propose that a clearer, more direct message be used.
> > Something like "Warning: kernel maintainers may not support your kernel
> > since you have loaded %s: %s%s\n" would be much more informative and
> > correct.
>
> More informative but I think too soft. It still implies we might want to
> hear about it but not reply. That isnt the case.
What you say is true enough if you speak for yourself and/or the core
cadre of kernel maintainers. On the other hand, the linux-kernel list
has been and mostly continues to be a good place to get help with
problems related to kernel changes that affect non-GPL modules.
To put it another way, the kernel developers aren't necessarily the
target audience when a request for assistance is posted to linux-kernel.
If that was too subtle, kernel developers aren't the only people who
read linux-kernel. Is linux-kernel an appropriate venue for such
assistance requests? Maybe not the *most* appropriate one, but it's
often the most efficient. Let me put it this way: speaking for myself,
I don't ask linux-kernel list readers for help with a problem if the
problem isn't the immediate result of a kernel change.
--
-----------------------------------------------------------------------
Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org
[email protected]
-----------------------------------------------------------------------
On Sat, 2002-04-27 at 11:20, Alan Cox wrote:
> How about
>
> Warning: The module you have loaded (%s) does not seem to have an open
> source license. Please send any kernel problem reports to the
> author of this module, or duplicate them from a boot without
> ever loading this module before reporting them to the community
> or your Linux vendor
Perfect. A little long, but otherwise nails it.
Maybe we want to s/open source/GPL-compatible/ though?
Robert Love
Richard Thrapp <[email protected]> :
[...]
> That doesn't fix the problem. The message is still wrong. A reference
> to an explanation only helps the people who can reach it immediately.
> Linux is also used on manufacturing floors (and several other places)
> where no network connections exist.
Aunt Tillie try to insmod a binary-only module on production server and ...
Please, kernel maintainers are way harder to bother without network connection.
It was the first goal of tainting, wasn't it ?
--
Ueimor
> What about:
> "WARNING: You are about to leaving the american sector."?
Wrong way around surely 8)
> Well a smart user could eliminate the tainted stuff and get support
> anyway.
> What's the point of having such a message ? I think it's trivial to get
> rid of it anyway.
Smart users are not the problem. Most of the problems are generated by
people who simply don't know better. If you know enough to remove the message
you generally know enough to try with and without and send a useful report
Today, Alan Cox wrote:
> How about
>
> Warning: The module you have loaded (%s) does not seem to have an open
> source license. Please send any kernel problem reports to the
> author of this module, or duplicate them from a boot without
> ever loading this module before reporting them to the community
> or your Linux vendor
I think you're making an assumption about the vendor's support statement
that may not be valid. If I were a distro I wouldn't appreciate modutils
makeing statements about my support policies and confusing the newbies,
who are after all the target audience here. I'd take that last "or your
Linux vendor." bit off of this.
Note that this wouldn't be an issue if no one shipped modules that taint
the kernel, however, I've seen modules on cds for two of the major distros
that would taint the kernel lately. (drivers/cdrom/cdrom.c was just
recenly corrected for example.) Of course if *no one* shipped modules that
taint the kernel then this whole thing wouldn't be an issue. :)
--
Never make a technical decision based upon the politics of the situation.
Never make a political decision based upon technical issues.
The only place these realms meet is in the mind of the unenlightened.
-- Geoffrey James, The Zen of Programming
> > author of this module, or duplicate them from a boot without
> > ever loading this module before reporting them to the community
> > or your Linux vendor
>
> I think you're making an assumption about the vendor's support statement
> that may not be valid. If I were a distro I wouldn't appreciate modutils
> makeing statements about my support policies and confusing the newbies,
> who are after all the target audience here. I'd take that last "or your
> Linux vendor." bit off of this.
This message is correct for just about every distribution. Remember vendors can
and do customise modutils anyway. I don't think its a problem.
Alan
On Sat, 27 Apr 2002 16:20:03 +0100 (BST),
Alan Cox <[email protected]> wrote:
>How about
>
>Warning: The module you have loaded (%s) does not seem to have an open
> source license. Please send any kernel problem reports to the
> author of this module, or duplicate them from a boot without
> ever loading this module before reporting them to the community
> or your Linux vendor
I'm going for the current message followed by "See <URL> for more
information". <URL> defaults to http://www.tux.org/lkml/#s1-18,
vendors who want to point to their policy text can override the URL
when they build modutils.
On 27 Apr 2002 10:51:52 -0500,
Richard Thrapp <[email protected]> wrote:
>On Sat, 2002-04-27 at 07:08, Francois Romieu wrote:
>> Richard Thrapp <[email protected]> :
>> [...]
>> > First of all, the current tainted message is not really useful.
>> > "Warning: Loading %s will taint the kernel..." isn't very informative at
>> > all. Most people don't know what it means to "taint the kernel". It's
>>
>> Add a reference to http://www.tux.org/lkml/#s1-18. An explanation is already
>> there.
>
>That doesn't fix the problem. The message is still wrong. A reference
>to an explanation only helps the people who can reach it immediately.
>Linux is also used on manufacturing floors (and several other places)
>where no network connections exist.
Those people can modify and ship a version of modutils that does not
issue the taint message. That makes it their problem, not ours. I
know of at least one embedded system distributer who is doing just
this.
If you want to ship binary only modules and you don't want your users
to question this, removal of the warning messages is your problem. GPL
allows anybody to change any messages they like as long as they supply
the changed source. I will not (cannot) stop people changing modutils
to defeat community expectations but I will not support them either.
On Sat, 2002-04-27 at 19:27, Keith Owens wrote:
> On Sat, 27 Apr 2002 16:20:03 +0100 (BST),
> Alan Cox <[email protected]> wrote:
> >How about
> >
> >Warning: The module you have loaded (%s) does not seem to have an open
> > source license. Please send any kernel problem reports to the
> > author of this module, or duplicate them from a boot without
> > ever loading this module before reporting them to the community
> > or your Linux vendor
>
> I'm going for the current message followed by "See <URL> for more
> information". <URL> defaults to http://www.tux.org/lkml/#s1-18,
> vendors who want to point to their policy text can override the URL
> when they build modutils.
Why did you tell me to ask here and go with what Alan said if you
weren't going to listen to the discussion? Alan's message corrects all
of the problems we found. Several people agreed on the basic form. If
you weren't going to go with the agreed upon result, why did you have me
ask here? You just wasted a lot of our time. You should have just told
me earlier that you weren't going to correct it -- I would have accepted
the decision.
I get sick and tired of maintainers who solicit opinions and then refuse
to listen to the answers they get back, even when people who know what
they are doing agree... even when the majority agrees. I've seen it
happen many times. I know it's the maintainer's choice in the end, but
don't ask for community opinions unless you're going to listen to them.
It's insulting and infuriating.
As for your correction, people aren't going to look up an URL in
general. It's too inconvenient. Many of them will probably just forget
about the message and report bugs to the wrong place anyway.
I provide a module, not a distribution. I've found that people want to
choose their distribution, even sometimes in embedded space, so I let
them (and I have no interest in providing a distribution anyway). I
cannot control what modutils they run. But I get bug reports back on
the module due to the tainted message.
At the very least, -please- change the verb tense of the message to be
correct. That will at least eliminate the "module doesn't load" bug
reports (I hope).
-- Richard Thrapp
On 27 Apr 2002 20:27:07 -0500,
Richard Thrapp <[email protected]> wrote:
>On Sat, 2002-04-27 at 19:27, Keith Owens wrote:
>> On Sat, 27 Apr 2002 16:20:03 +0100 (BST),
>> Alan Cox <[email protected]> wrote:
>> >How about
>> >
>> >Warning: The module you have loaded (%s) does not seem to have an open
>> > source license. Please send any kernel problem reports to the
>> > author of this module, or duplicate them from a boot without
>> > ever loading this module before reporting them to the community
>> > or your Linux vendor
>>
>> I'm going for the current message followed by "See <URL> for more
>> information". <URL> defaults to http://www.tux.org/lkml/#s1-18,
>> vendors who want to point to their policy text can override the URL
>> when they build modutils.
>
>Why did you tell me to ask here and go with what Alan said if you
>weren't going to listen to the discussion? Alan's message corrects all
>of the problems we found. Several people agreed on the basic form. If
>you weren't going to go with the agreed upon result, why did you have me
>ask here? You just wasted a lot of our time. You should have just told
>me earlier that you weren't going to correct it -- I would have accepted
>the decision.
The discussion was useful. I choose to agree with the people who
suggested a URL rather than with Alan's suggestion of an expanded
message. It allows vendors who want to support their customers
directly to add a reference to their policy and remove the load from
l-k.
That is what discussion is for, to bring out possibilities. If you
don't like my decision you are free to ship and maintain your own
modified version of modutils.
>I get sick and tired of maintainers who solicit opinions and then refuse
>to listen to the answers they get back, even when people who know what
>they are doing agree... even when the majority agrees. I've seen it
>happen many times. I know it's the maintainer's choice in the end, but
>don't ask for community opinions unless you're going to listen to them.
>It's insulting and infuriating.
Translation: "I don't like the decision so I will complain about the
maintainer". See above.
>I provide a module, not a distribution. I've found that people want to
>choose their distribution, even sometimes in embedded space, so I let
>them (and I have no interest in providing a distribution anyway). I
>cannot control what modutils they run. But I get bug reports back on
>the module due to the tainted message.
That is one of the many costs you have to bear for shipping binary only
modules. I am not going to make life easier for you. In your original
message to me you made no mention of the fact that you are shipping
binary only modules, if I had know that in advance I would not have
tried to help you, now you have no credibility with me.
>At the very least, -please- change the verb tense of the message to be
>correct. That will at least eliminate the "module doesn't load" bug
>reports (I hope).
The verb tense is correct. The message is issued before the module is
loaded and descibes what is about to occur.
> I get sick and tired of maintainers who solicit opinions and then refuse
> to listen to the answers they get back, even when people who know what
> they are doing agree... even when the majority agrees. I've seen it
Keith listened, and disagreed then proposed an alternative. Its his
package, its his business to do that.
> At the very least, -please- change the verb tense of the message to be
> correct. That will at least eliminate the "module doesn't load" bug
> reports (I hope).
That bit does want fixing to be less confusing either way
Keith, I apologize for my rash words. I clicked send before I cooled
down, and I should know better. I care a lot about my work. I am
sorry.
On Sat, 2002-04-27 at 20:41, Keith Owens wrote:
> On 27 Apr 2002 20:27:07 -0500,
> Richard Thrapp <[email protected]> wrote:
> >On Sat, 2002-04-27 at 19:27, Keith Owens wrote:
> That is one of the many costs you have to bear for shipping binary only
> modules. I am not going to make life easier for you. In your original
> message to me you made no mention of the fact that you are shipping
> binary only modules, if I had know that in advance I would not have
> tried to help you, now you have no credibility with me.
I thought it was pretty obvious that I was shipping a non-GPL module
(not binary-only). But that is not my only interest. I have given time
and thought to many open source projects. I genuinely wanted a more
informative error message.
> >At the very least, -please- change the verb tense of the message to be
> >correct. That will at least eliminate the "module doesn't load" bug
> >reports (I hope).
>
> The verb tense is correct. The message is issued before the module is
> loaded and descibes what is about to occur.
>From the point of view of the user, who sees the message after the
module is loaded, it is incorrect and implies that the module wasn't
loaded.
-- Richard Thrapp
On Sat, 2002-04-27 at 09:57, Robert Love wrote:
> On Sat, 2002-04-27 at 11:20, Alan Cox wrote:
>
> > How about
> >
> > Warning: The module you have loaded (%s) does not seem to have an open
> > source license. Please send any kernel problem reports to the
> > author of this module, or duplicate them from a boot without
> > ever loading this module before reporting them to the community
> > or your Linux vendor
>
> Perfect. A little long, but otherwise nails it.
>
Warning: The module (%s) does not seem to have a compatible license.
Please contact the supplier of this module regarding any
problems, or reproduce the problem after rebooting without
ever loading this module.
shorter?
> Maybe we want to s/open source/GPL-compatible/ though?
>
> Robert Love
>
> -
> To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
> the body of a message to [email protected]
> More majordomo info at http://vger.kernel.org/majordomo-info.html
> Please read the FAQ at http://www.tux.org/lkml/
> > > Warning: The module you have loaded (%s) does not seem to have an open
> > > source license. Please send any kernel problem reports to the
> > > author of this module, or duplicate them from a boot without
> > > ever loading this module before reporting them to the community
> > > or your Linux vendor
> >
> > Perfect. A little long, but otherwise nails it.
> >
> Warning: The module (%s) does not seem to have a compatible license.
> Please contact the supplier of this module regarding any
> problems, or reproduce the problem after rebooting without
> ever loading this module.
>
> shorter?
I don't think you can strip the part about open-ness of the code --
it's an essential part of the explanation. And "any problems" might
be too broad.
Moreover, it would make sense - I believe - to include a conditional
like "Should you encounter problems after ...", as the message, as
it stands in this proposal, is rather scary: It seems to tell the
user to *do* expect problems.
T.
--
"hello it's not like i read my mail so that you have where to offer to sell me
a giant turnip or anything else thankyou." -tomas szepe <[email protected]>
tomas szepe Awoke this dragon, who will now respond:
> > Warning: The module (%s) does not seem to have a compatible license.
> > Please contact the supplier of this module regarding any
> > problems, or reproduce the problem after rebooting without
> > ever loading this module.
> >
> > shorter?
>
> I don't think you can strip the part about open-ness of the code --
> it's an essential part of the explanation. And "any problems" might
> be too broad.
Moreover, I think the 'compatible license thing doesnt fly.
the argument against CLOSE modules is that they make the _whole_package_
undebuggable.
if the source is available, no matter HOW crippling its license, the
package _IS_ debuggable.
thie warning should be:
Warning: Module %s is not open source, and as such, loading it will make
your kernel un-debuggable. Please do not submit bug reports from a kernel
with this module loaded, as they will be useless, and likely ignored.
On Mon, 29 Apr 2002, Ian Molton wrote:
> tomas szepe Awoke this dragon, who will now respond:
>
> > > Warning: The module (%s) does not seem to have a compatible license.
> > > Please contact the supplier of this module regarding any
> > > problems, or reproduce the problem after rebooting without
> > > ever loading this module.
> > >
> > > shorter?
> >
> > I don't think you can strip the part about open-ness of the code --
> > it's an essential part of the explanation. And "any problems" might
> > be too broad.
>
> Moreover, I think the 'compatible license thing doesnt fly.
>
> the argument against CLOSE modules is that they make the _whole_package_
> undebuggable.
>
> if the source is available, no matter HOW crippling its license, the
> package _IS_ debuggable.
>
> thie warning should be:
>
> Warning: Module %s is not open source, and as such, loading it will make
> your kernel un-debuggable. Please do not submit bug reports from a kernel
> with this module loaded, as they will be useless, and likely ignored.
well, that's not the truth: the kernel itself is debuggable, but we don't
know about the module, and how the module interacts with the
kernel.
why not simply state that "the source to this module doesn't seem to be
available..." ?
tm
--
in some way i do, and in some way i don't.
> tomas szepe Awoke this dragon, who will now respond:
>
> > > Warning: The module (%s) does not seem to have a compatible license.
> > > Please contact the supplier of this module regarding any
> > > problems, or reproduce the problem after rebooting without
> > > ever loading this module.
> > >
> > > shorter?
> >
> > I don't think you can strip the part about open-ness of the code --
> > it's an essential part of the explanation. And "any problems" might
> > be too broad.
>
> Moreover, I think the 'compatible license thing doesnt fly.
>
> the argument against CLOSE modules is that they make the _whole_package_
> undebuggable.
>
> if the source is available, no matter HOW crippling its license, the
> package _IS_ debuggable.
>
> thie warning should be:
>
> Warning: Module %s is not open source, and as such, loading it will make
> your kernel un-debuggable. Please do not submit bug reports from a kernel
> with this module loaded, as they will be useless, and likely ignored.
Very good! I'd only change the tense to "The non-opensource module %s is
about to be loaded, which will make your kernel impossible to debug," so
that it's crystal clear that the message is not a failure notification.
T.
--
"hello it's not like i read my mail so that you have where to offer to sell me
a giant turnip or anything else thankyou." -tomas szepe <[email protected]>
Thomas 'Dent' Mirlacher Awoke this dragon, who will now respond:
> > Warning: Module %s is not open source, and as such, loading it will
> > make your kernel un-debuggable. Please do not submit bug reports from
> > a kernel with this module loaded, as they will be useless, and likely
> > ignored.
>
> well, that's not the truth: the kernel itself is debuggable, but we
> don't know about the module, and how the module interacts with the
> kernel.
It absolutely IS the truth.
what happens if an errant module clobbers kernel space?
Ian Molton wrote:
> Warning: Module %s is not open source, and as such, loading it will make
> your kernel un-debuggable. Please do not submit bug reports from a kernel
> with this module loaded, as they will be useless, and likely ignored.
looks perfect.
greetings
Christian
> > > Warning: Module %s is not open source, and as such, loading it will
> > > make your kernel un-debuggable. Please do not submit bug reports from
> > > a kernel with this module loaded, as they will be useless, and likely
> > > ignored.
> > well, that's not the truth: the kernel itself is debuggable, but we
> > don't know about the module, and how the module interacts with the
> > kernel.
> It absolutely IS the truth.
> what happens if an errant module clobbers kernel space?
And isn't it true any more that modules can "shadow" certain kernel functions?
T.
Christian Borntr?ger wrote:
>
> Ian Molton wrote:
> > Warning: Module %s is not open source, and as such, loading it will make
> > your kernel un-debuggable. Please do not submit bug reports from a kernel
> > with this module loaded, as they will be useless, and likely ignored.
Warning: Source code for module %s is not publicly available. Problems
with a kernel that has loaded this module can be debugged only by someone
with access to the module source. Therefore, please submit any bug reports
to the module supplier, not to the Linux kernel mailing list.
On Mon, 29 Apr 2002 19:42:32 +0200, tomas szepe <[email protected]>
wrote:
>> tomas szepe Awoke this dragon, who will now respond:
>>
>> > > Warning: The module (%s) does not seem to have a compatible license.
>> > > Please contact the supplier of this module regarding any
>> > > problems, or reproduce the problem after rebooting without
>> > > ever loading this module.
>> > >
>> > > shorter?
>> >
>> > I don't think you can strip the part about open-ness of the code --
>> > it's an essential part of the explanation. And "any problems" might
>> > be too broad.
>>
>> Moreover, I think the 'compatible license thing doesnt fly.
>>
>> the argument against CLOSE modules is that they make the _whole_package_
>> undebuggable.
>>
>> if the source is available, no matter HOW crippling its license, the
>> package _IS_ debuggable.
>>
>> thie warning should be:
>>
>> Warning: Module %s is not open source, and as such, loading it will make
>> your kernel un-debuggable. Please do not submit bug reports from a kernel
>> with this module loaded, as they will be useless, and likely ignored.
>
>Very good! I'd only change the tense to "The non-opensource module %s is
>about to be loaded, which will make your kernel impossible to debug," so
>that it's crystal clear that the message is not a failure notification.
Pschologically it would be better to phrase it as a postive statement.
Warning: Module %s is not open source, and as such, loading it will
make your kernel un-debuggable. Before reporting problems to
Linux-kernel, please replicate the problem without the module loaded.
john alvord
> >> > > Warning: The module (%s) does not seem to have a compatible license.
> >> > > Please contact the supplier of this module regarding any
> >> > > problems, or reproduce the problem after rebooting without
> >> > > ever loading this module.
> >> > >
> >> > > shorter?
> >> >
> >> > I don't think you can strip the part about open-ness of the code --
> >> > it's an essential part of the explanation. And "any problems" might
> >> > be too broad.
> >>
> >> Moreover, I think the 'compatible license thing doesnt fly.
> >>
> >> the argument against CLOSE modules is that they make the _whole_package_
> >> undebuggable.
> >>
> >> if the source is available, no matter HOW crippling its license, the
> >> package _IS_ debuggable.
> >>
> >> thie warning should be:
> >>
> >> Warning: Module %s is not open source, and as such, loading it will make
> >> your kernel un-debuggable. Please do not submit bug reports from a kernel
> >> with this module loaded, as they will be useless, and likely ignored.
> >
> >Very good! I'd only change the tense to "The non-opensource module %s is
> >about to be loaded, which will make your kernel impossible to debug," so
> >that it's crystal clear that the message is not a failure notification.
>
> Pschologically it would be better to phrase it as a postive statement.
>
> Warning: Module %s is not open source, and as such, loading it will
> make your kernel un-debuggable. Before reporting problems to
> Linux-kernel, please replicate the problem without the module loaded.
You're right. And, hmmm, tell you what.. I also like your version because
it makes no statements whatsoever about vendor support, or support from
anyone else than the people on linux-kernel.
Now, would anyone attempt to sum up all the points made here and come up
w/ something like a "final-draft" proposal?
T.
tomas szepe wrote:
> > >> thie warning should be:
> > >>
> > >> Warning: Module %s is not open source, and as such, loading it will make
> > >> your kernel un-debuggable. Please do not submit bug reports from a kernel
> > >> with this module loaded, as they will be useless, and likely ignored.
> > >
> > >Very good! I'd only change the tense to "The non-opensource module %s is
> > >about to be loaded, which will make your kernel impossible to debug," so
> > >that it's crystal clear that the message is not a failure notification.
> >
> > Pschologically it would be better to phrase it as a postive statement.
> >
> > Warning: Module %s is not open source, and as such, loading it will
> > make your kernel un-debuggable. Before reporting problems to
> > Linux-kernel, please replicate the problem without the module loaded.
>
> You're right. And, hmmm, tell you what.. I also like your version because
> it makes no statements whatsoever about vendor support, or support from
> anyone else than the people on linux-kernel.
>
> Now, would anyone attempt to sum up all the points made here and come up
> w/ something like a "final-draft" proposal?
Warning: Source code for module %s is not publicly available. Problems
with a kernel that has loaded this module can be debugged only by someone
with access to the module source. Before reporting a problem to the Linux
kernel mailing list, please replicate the problem without the module loaded.
> > > >> thie warning should be:
> > > >>
> > > >> Warning: Module %s is not open source, and as such, loading it will make
> > > >> your kernel un-debuggable. Please do not submit bug reports from a kernel
> > > >> with this module loaded, as they will be useless, and likely ignored.
> > > >
> > > >Very good! I'd only change the tense to "The non-opensource module %s is
> > > >about to be loaded, which will make your kernel impossible to debug," so
> > > >that it's crystal clear that the message is not a failure notification.
> > >
> > > Pschologically it would be better to phrase it as a postive statement.
> > >
> > > Warning: Module %s is not open source, and as such, loading it will
> > > make your kernel un-debuggable. Before reporting problems to
> > > Linux-kernel, please replicate the problem without the module loaded.
> >
> > You're right. And, hmmm, tell you what.. I also like your version because
> > it makes no statements whatsoever about vendor support, or support from
> > anyone else than the people on linux-kernel.
> >
> > Now, would anyone attempt to sum up all the points made here and come up
> > w/ something like a "final-draft" proposal?
>
> Warning: Source code for module %s is not publicly available. Problems
> with a kernel that has loaded this module can be debugged only by someone
> with access to the module source. Before reporting a problem to the Linux
> kernel mailing list, please replicate the problem without the module loaded.
Indeed, this would certainly do much better than the current caption.
"What say you, Mr. ModutilsMaintainer?" <wink wink>
T.
On Mon, 29 Apr 2002 21:21:07 +0200,
tomas szepe <[email protected]> wrote:
>Now, would anyone attempt to sum up all the points made here and come up
>w/ something like a "final-draft" proposal?
What next, gcc warnings that include sections of the C99 standard or
chunks of the info entry? There are reasons that documentation is
separate from error and warning messages.
Summary:
Nobody can agree on the warning text. Anything less than the full
kernel FAQ entry is incomplete.
Vendors who ship binary modules and support their users should use
different text, pointing to the vendor's support policy instead of
bothering linux-kernel.
Solution:
modutils 2.4.16 says
Warning: loading <module> will taint the kernel. Reason <reason>
See <TAINT_URL> for information on tainted modules
Module loaded, with warnings
Printing 'Module loaded, with warnings' makes it clear that the
module has been loaded. TAINT_URL defaults to lkml FAQ. Vendors can
ship modutils with a TAINT_URL that points to their support policy.
> Nobody can agree on the warning text. Anything less than the full
> kernel FAQ entry is incomplete.
Hey, no need for sarcasm here; I don't think the four lines could offend
anyone, being merely a different solution proposal. Yours is pretty good
too.
> Solution:
>
> modutils 2.4.16 says
>
> Warning: loading <module> will taint the kernel. Reason <reason>
> See <TAINT_URL> for information on tainted modules
> Module loaded, with warnings
>
> Printing 'Module loaded, with warnings' makes it clear that the
> module has been loaded. TAINT_URL defaults to lkml FAQ. Vendors can
> ship modutils with a TAINT_URL that points to their support policy.
Neat!
T.
On Tue, Apr 30, 2002 at 09:06:14AM +1000, Keith Owens wrote:
> Solution:
>
> modutils 2.4.16 says
>
> Warning: loading <module> will taint the kernel. Reason <reason>
> See <TAINT_URL> for information on tainted modules
> Module loaded, with warnings
>
> Printing 'Module loaded, with warnings' makes it clear that the
> module has been loaded. TAINT_URL defaults to lkml FAQ. Vendors can
> ship modutils with a TAINT_URL that points to their support policy.
how about adding an optional tag to modules for a support/faq URL?
there's no real need to add it for stuff in the kernel tree (unlike the
license tag stuff) but external projects could make good use of it.
sounds much better to me than arguing over the subtleties of the warning
message.
j.
--
R N G G "Well, there it goes again... And we just sit
I G G G here without opposable thumbs." -- gary larson
On Tue, 30 Apr 2002 23:37:32 +1000,
john slee <[email protected]> wrote:
>how about adding an optional tag to modules for a support/faq URL?
It is already there!
MODULE_LICENSE("Proprietary FOO P/L - contact someone@somewhere for support");
insmod prints the license text.
> Re: The tainted message
>
>
> Christian Borntr?ger wrote:
> >
> > Ian Molton wrote:
> > > Warning: Module %s is not open source, and as such, loading it will make
> > > your kernel un-debuggable. Please do not submit bug reports from a kernel
> > > with this module loaded, as they will be useless, and likely ignored.
>
> Warning: Source code for module %s is not publicly available. Problems
> with a kernel that has loaded this module can be debugged only by someone
> with access to the module source. Therefore, please submit any bug reports
> to the module supplier, not to the Linux kernel mailing list.
> -
The one on top is IMHO better. The reason is that the wording of the
second one, although giving better explanation why it (may) make the
kernel undebuggable, implicitely suggests (to me as a nonative english
speaker) that the problem is caused by the non compatibly licensed
module. Which I venture is not true in a lot of cases.
Also, in both messages it is stated that the source is not publicly
available. This is not obvious to me. The module may just lack an
explicitely stated license. Maybe just a case of not RTFMing the modules
documentation, or an old source that hasn't been touched since
introduction of the tainting stuff.
So, I would prefer:
"Warning: Source code for module %s may not be publicly available.
Problems
with a kernel that has loaded this module can be debugged only by
someone
with access to the module source. Therefore, please do not submit any
bug
reports to the Linux kernel mailing list unless you can reproduce them
without having this module loaded."
As for using the term "tainted" in the warning: I do not like it,
because it has a absolutely negative meaning if translated into German
and maybe (likely?) other languanges. This could give the impression
that the warning tries to tell the user that non-compatibly licensed
modules are [the source of all] evil. Some of them may be evil, but I do
not buy this concept in general.
Martin
--
------------------------------------------------------------------
Martin Knoblauch | email: [email protected]
TeraPort GmbH | Phone: +49-89-510857-309
C+ITS | Fax: +49-89-510857-111
http://www.teraport.de | Mobile: +49-170-4904759