Date:	Thu, 25 Sep 2008 15:04:54 -0700
From:	Greg KH <gregkh@...e.de>
To:	Parag Warudkar <parag.lkml@...il.com>
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 Thu, Sep 25, 2008 at 05:40:28PM -0400, Parag Warudkar wrote:
> On Thu, Sep 25, 2008 at 4:53 PM, Greg KH <gregkh@...e.de> wrote:
> >
> > Heh, ok, so the basic premise of getting code that is not currently in
> > mergable shape into the tree earlier to get wider usage and testing is
> > something that you agree with?
> 
> I don't think I got my point across - let me try again.
> 
> My disagreement was with getting crap code in mainline, re-classifying
> it as something other than experimental when it is not, expecting
> users to use it, printing warning when it is used, tainting the kernel
> for even more harassment and then having developers not support it  as
> a bonus - all cumulative. The naming part was also something that I
> did not like but that like I said was just my preference and does not
> matter because I disagree there is no need to TAINT  in first place.

I'm sorry we disagree here.  Also note that this goes against what a
number of us decided at the kernel summit, we want this code into the
tree as easily as possible.

> I can imagine that getting crap code in mainline is helpful for some
> class of users and developers - no problem we can have it in on that
> basis - I give up my objection there.

Great.

> But my objections to the other parts remain -  i.e. we should
> definitely avoid the useless re-classification and TAINT, we should
> change little or no other kernel code in the process of integrating
> this crap, give enough deterrent for people to really think before
> loading the crap code, and do not make it an official statement that
> you will get no support on LKML if you load this driver. Because
> certainly not all developers agree and we by definition of this
> staging effort have an interest in fixing the code.
> 
> The below approach I referred few times earlier will allow us to do
> exactly that - it would be good if you can tell me if this is
> workable.

So you now agree with the idea, just the implementation of the area
around the drivers, nice that's easy to work out.

> 1) Give a staging directory for all such low quality crap

Done in the patches I sent out.

> 2) Give a KConfig group "Staging Drivers (Low Quality/High Risk)" and
> if that is selected allow users to individually select the crappy
> drivers they want to actually use - default all entries to N

Done in the patches I sent out.

> 3) Name all modules under staging  with a _stg suffix or something unique

A name doesn't really matter here, the modinfo tag is just as
sufficient like I already did.

> 4) By default do NOT load anything with a _stg suffix - deal with this
> in insmod code, not the kernel

Um, no, I'm not going to force all userspace users to upgrade their
version of module-init-tools, JUST to prevent them from automatically
loading these drivers.  That's not going to happen, sorry.

> 5) Require that -f be specified to load _stg modules - which will
> auto-taint the kernel and developers can decide on their judgment /
> situation whether or not to pursue it

So you have to load the modules by "hand"?  Ick, no, that too is not
acceptable as it means no one will ever do it.  Don't break the
wonderful infrastructure we already have around the kernel of
auto-loading the proper driver for the proper hardware just because you
want to make the user jump through an extra step please.

>  6) OOPS reports with force loaded taint and _stg in module list will
> allow developers to decide whether or not to go after it

My patch set already does this, and it does so in a way that uniquely
distinguishes from the -f option, which some of us don't want to debug
as well.

> The above approach avoids re-classification/TAINTING, touches no
> kernel code and does not load the crap code automatically and still
> allows you to do what you intended.

What's the objection for the 9 extra lines in module.c, 2 lines in
panic.c, and 9 lines on scripts/mod/modpost.c?  Is this some huge
overhead that is unmaintainable?

Heck, the insmod changes would be more than that I imagine (and it would
be in modprobe, not insmod, it has to do with alias matching and that
chunk of code is _nasty_, I sure don't want to touch that.)

> Hopefully this doesn't sound like another "let us arm wrestle on what
> to name it" - because it is clearly more than that!

No, I really think it isn't more than that.  For some reason you are
afraid of another taint flag, why?  There is no extra overhead, and no
user needs to upgrade any userspace component at all (which, if you have
any experience with, you will know it just will not happen fast, if at
all for the large majority of users/developers.)

I don't want to make the kernel require a new version of
module-init-tools, and my current proposal of infrastructure changes
requires a massive core change of:

 Documentation/sysctl/kernel.txt |    1 +
 include/linux/kernel.h          |    1 +
 kernel/module.c                 |    9 +++++++++
 kernel/panic.c                  |    6 ++++--
 scripts/mod/modpost.c           |    9 +++++++++
5 files changed, 24 insertions(+), 2 deletions(-)

How much smaller do you expect this to get?

thanks,

greg k-h
--
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