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
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
-
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/
Quoted 4 lines
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
Quoted 3 lines · 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
Quoted 4 lines
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]> :
[...]
Quoted 3 lines
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.
Signature · 1 line
Ueimor
Quoted 8 lines · Francois Romieu
Richard Thrapp <[email protected]> :
[...]Quoted 3 lines
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
Quoted 7 lines · Richard Thrapp
Quoted 6 lines · Francois Romieu
Richard Thrapp <[email protected]> :
[...]Quoted 3 lines
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
Quoted 7 lines
Quoted 2 lines
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.
Quoted 3 lines
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.
Quoted 6 lines
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
??
Quoted 10 lines
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."?
Quoted 2 lines
What about:
"WARNING: You are about to leaving the american sector."?
Wrong way around surely 8)
Quoted 5 lines · Alan Cox
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
Quoted 7 lines
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
Quoted 7 lines · Alan Cox
Quoted 4 lines
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.
Signature · 4 lines
----------------------------------------------------------------------- Bob Tracy WTO + WIPO = DMCA? http://www.anti-dmca.org [email protected] -----------------------------------------------------------------------
Quoted 7 lines · Alan Cox
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
Quoted 4 lines · Robert Love
Quoted 2 lines · Alan Cox
How about
Quoted 8 lines
Quoted 5 lines
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 vendorPerfect. 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?
Quoted 9 lines
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/
Quoted 7 lines · Alan Cox
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. :)
Signature · 4 lines
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
Quoted 9 lines
Quoted 3 lines
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
Quoted 7 lines · Alan Cox
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.
Quoted 10 lines · Keith Owens
Quoted 7 lines · Alan Cox
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
Quoted 4 lines
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
Quoted 16 lines · Richard Thrapp
Quoted 10 lines · Keith Owens
Quoted 7 lines · Alan Cox
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 vendorQuoted 4 lines
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.
Quoted 7 lines
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.
Quoted 6 lines
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.
Quoted 5 lines
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.
Quoted 3 lines
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.
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.
Quoted 8 lines · Keith Owens
Quoted 1 line · Richard Thrapp
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.
Quoted 8 lines
Quoted 3 lines
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
Quoted 3 lines
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.
Quoted 3 lines
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
Quoted 6 lines
Quoted 6 lines
Quoted 5 lines
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
Quoted 8 lines
Quoted 2 lines
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.
Signature · 2 lines
"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:
Quoted 10 lines
Quoted 6 lines
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.
Quoted 18 lines · Ian Molton
tomas szepe Awoke this dragon, who will now respond:
Quoted 10 lines
Quoted 6 lines
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.
Quoted 8 lines
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
Signature · 1 line
in some way i do, and in some way i don't.
Thomas 'Dent' Mirlacher Awoke this dragon, who will now respond:
Quoted 8 lines
Quoted 4 lines
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?
Quoted 9 lines
Quoted 7 lines
Quoted 4 lines
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.
Quoted 18 lines
tomas szepe Awoke this dragon, who will now respond:
Quoted 10 lines
Quoted 6 lines
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.
Quoted 8 lines
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.
Signature · 2 lines
"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]>
Quoted 3 lines · Ian Molton
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
Quoted 5 lines · Christian Bornträger
Quoted 3 lines · Ian Molton
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.
Quoted 23 lines · tomas szepe
Quoted 23 lines
tomas szepe Awoke this dragon, who will now respond:
Quoted 10 lines
Quoted 6 lines
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:
Quoted 7 lines
Quoted 3 lines
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
Quoted 29 lines
Quoted 21 lines
Quoted 21 lines
Quoted 10 lines
Quoted 6 lines
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:
Quoted 7 lines
Quoted 3 lines
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.
Quoted 5 lines
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.
Quoted 2 lines · tomas szepe
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.
Quoted 2 lines
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.
Quoted 11 lines
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 warningsPrinting 'Module loaded, with warnings' makes it clear that the module has been loaded.
TAINT_URLdefaults to lkml FAQ. Vendors can ship modutils with aTAINT_URLthat points to their support policy.
Neat!
T.
Quoted 11 lines · Keith Owens
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 warningsPrinting 'Module loaded, with warnings' makes it clear that the module has been loaded.
TAINT_URLdefaults to lkml FAQ. Vendors can ship modutils with aTAINT_URLthat 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.
Signature · 2 lines
R N G G "Well, there it goes again... And we just sit I G G G here without opposable thumbs." -- gary larson
Quoted 1 line · john slee
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.
Quoted 16 lines · tomas szepe
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 6 lines
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.
Quoted 20 lines
Quoted 20 lines
Quoted 10 lines
Quoted 9 lines
Quoted 5 lines
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.
Quoted 5 lines
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.
Quoted 7 lines
Quoted 2 lines
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.
was: Re: The tainted message
In reply to Richard ThrappRichard Thrapp <[email protected]> :
[...]
Quoted 4 lines
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 ?
Signature · 1 line
Ueimor