[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <f7848160809241639hbe716c9q76b0e1b83d853721@mail.gmail.com>
Date: Wed, 24 Sep 2008 19:39:42 -0400
From: "Parag Warudkar" <parag.lkml@...il.com>
To: "Greg KH" <gregkh@...e.de>
Cc: "Linus Torvalds" <torvalds@...ux-foundation.org>,
"Andrew Morton" <akpm@...ux-foundation.org>,
linux-kernel@...r.kernel.org,
"Andreas Gruenbacher" <agruen@...e.de>,
"Jeff Mahoney" <jeffm@...e.de>
Subject: Re: [patch 00/04] RFC: Staging tree (drivers/staging)
On Wed, Sep 24, 2008 at 7:00 PM, Greg KH <gregkh@...e.de> wrote:
> So, does this all look good to everyone? Any questions/issues?
>
I sure hope this does not end up like EXPERIMENTAL although it
essentially does duplicate the intent of EXPERIMENTAL.
(In other words - drivers live there for ever in staging mode, we
print warnings and generally nobody cares about the problem since the
kernel is tainted.)
That aside please at least substitute the word CRAP with something
better - like TAINT_NON_PRODUCTION or TAINT_UNRELIABLE or
TAINT_WORK_IN_PROGRESS or TAINT_EXPERIMENTAL . Arguably
TAINT_EXPERIMENTAL could also be used for known broken
CONFIG_EXPERIMENTAL items. It might also be better to change the
staging directory name to non-production or experimental - but that's
just my preference.
Also, I suppose it would be useful for Production machines to have a
kernel command line flag or something to say don't load staging
modules - for instance to prevent against automatic loading on drivers
from staging directory to support some oddball device etc.
Thinking more about it - could this whole thing not be achieved by
setting per module experimental flag and refusing to insmod'ing
experimental modules if -f was not specified. I believe force loading
also taints the kernel? All drivers intended for staging can set that
flag - this way we don't need another TAINT flag and there is no need
for the directory name hack.
Parag
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists