From: Jan-Benedict Glaw <jbglaw@lug-owl.de>
To: linux-kernel@vger.kernel.org
Subject: Re: Linux 2.4.9-ac6
Date: Wed, 5 Sep 2001 14:23:18 +0200 [thread overview]
Message-ID: <20010905142318.B20609@lug-owl.de> (raw)
In-Reply-To: <NOEJJDACGOHCKNCOGFOMAEAPDLAA.davids@webmaster.com> <E15ebSj-0005ig-00@the-village.bc.nu> <3B9617BA.F771914E@redhat.com>
In-Reply-To: <3B9617BA.F771914E@redhat.com>; from arjanv@redhat.com on Wed, Sep 05, 2001 at 01:16:58PM +0100
On Wed, 2001-09-05 13:16:58 +0100, Arjan van de Ven <arjanv@redhat.com>
wrote in message <3B9617BA.F771914E@redhat.com>:
> Alan Cox wrote:
> > > based upon whether you have the source or not. What should logically taint
> > > the kernel are modules that weren't compiled for that exact kernel version
> > > or are otherwise mismatched.
> > Setting a flag for the insmod -f required case as well is an extremely good
> > idea. This is entirely about making information available nothing else and
> > your suggestion there is a good one.
>
> How about making the "tainted" field a bitmask ?
> eg bit 0 --> non GPL/BSD module
> bit 1 --> insmod -f
Basically, I don't like that idea. 'insmod -f' should only be
required if the module in question is some kind of a commercial (TM)
module. Setting a "GPL/BSD" flag might be somewhat interesting
(but enlarges needed on-disk-space), but I don't like to help
those commercials to ease the use of their broken, binary-only
modules.
MfG, JBG
--
Jan-Benedict Glaw . jbglaw@lug-owl.de . +49-172-7608481
next prev parent reply other threads:[~2001-09-05 12:23 UTC|newest]
Thread overview: 37+ messages / expand[flat|nested] mbox.gz Atom feed top
2001-09-03 1:50 Linux 2.4.9-ac6 Alan Cox
2001-09-03 2:51 ` Keith Owens
2001-09-03 3:08 ` Dave Jones
2001-09-03 13:05 ` Andrea Arcangeli
2001-09-03 13:21 ` Alan Cox
2001-09-05 1:51 ` Keith Owens
2001-09-05 3:30 ` David Schwartz
2001-09-05 3:50 ` Keith Owens
2001-09-05 5:16 ` David Schwartz
2001-09-05 5:39 ` Alan Shutko
2001-09-05 18:46 ` David Schwartz
2001-09-05 5:52 ` H. Peter Anvin
2001-09-05 5:56 ` Aaron Lehmann
2001-09-05 7:03 ` David Schwartz
2001-09-05 7:09 ` David Schwartz
2001-09-05 9:50 ` Alex Bligh - linux-kernel
2001-09-05 9:57 ` David Schwartz
2001-09-05 12:50 ` christophe barbé
2001-09-05 13:06 ` Alan Cox
2001-09-05 13:14 ` Alex Bligh - linux-kernel
2001-09-05 13:23 ` christophe barbé
2001-09-05 14:05 ` Henning P. Schmiedehausen
2001-09-05 7:18 ` Aaron Lehmann
2001-09-05 7:19 ` David Schwartz
2001-09-05 9:41 ` Justin Guyett
2001-09-05 9:53 ` David Schwartz
2001-09-05 10:21 ` Justin Guyett
2001-09-05 11:55 ` Alan Cox
2001-09-05 18:46 ` David Schwartz
2001-09-05 18:54 ` Alan Cox
2001-09-05 22:09 ` Linux 2.4.9-ac6 (really about tainting) David Schwartz
2001-09-05 12:07 ` Linux 2.4.9-ac6 Alan Cox
2001-09-05 12:16 ` Arjan van de Ven
2001-09-05 12:23 ` Jan-Benedict Glaw [this message]
-- strict thread matches above, loose matches on Subject: below --
2001-09-05 14:36 Thomas Foerster
2001-09-06 19:23 ` Camiel Vanderhoeven
2001-09-06 20:14 ` Alan Cox
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20010905142318.B20609@lug-owl.de \
--to=jbglaw@lug-owl.de \
--cc=linux-kernel@vger.kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox