Re: [PATCH] Blacklist binary-only modules lying about their license

[Marc Boucher <marc@linuxant.com>]

On May 1, 2004, at 1:07 AM, Martin J. Bligh wrote:

>> All bugs can be debugged or fixed, it's a matter of how hard it is
>> to do (generally easier with open-source) and *who* is responsible
>> for doing it (i.e. supporting the modules).
>
> Yes, exactly. The tainted mechanism is there to tell us that it's not
> *our* problem to support it. And you deliberately screwed that up,
> which is why everybody is pissed at you.

It was already screwed up, and causing unnecessary support burdens
both on the community ("help! what does tainted mean") and vendors.
This thread and previous ones have shown ample evidence of that.
Let's deal with the root problem and fix the messages, as Rik van Riel
has suggested.

Most third-party module suppliers have been confronted with the same 
issue
and forced to work around it (in other imperfect and sometimes clumsy 
ways).
One of them redirects the messages to a separate file and appends
the following notice:

 > ********************************************************************
 > * You can safely ignore the above message about tainting the kernel.
 > * It is completely political and means just that the maintainers of
 > * of modutils package dislike software that is not distributed under
 > * an open source license.
 > ********************************************************************

On Apr 30, 2004, at 10:36 PM, Tim Connors wrote:
>
> What's wrong with the printk setting workaround? Simply write a number
> to the appropriate file before you load the modules.
>
> I just tried googling for the relevant post, but failed...
>
> He doesn't need to wait for the patches to propogate. He can act on
> his own scripts immediately in readiness for the next version.
>
> Easy.

Not. We don't use a script to systematically load the modules,
because they are large and not always required, nor want to
interfere with the system's normal logging.

Manipulating printk settings or redirecting the superfluous
messages elsewhere are also ugly hacks, which can
potentially also divert/hide important messages.

Marc