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

[Tigran Aivazian]

On Tue, 27 Apr 2004, Steve Lee wrote:

> 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

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/