public inbox for linux-kernel@vger.kernel.org
 help / color / mirror / Atom feed
From: Greg KH <gregkh@suse.de>
To: Parag Warudkar <parag.lkml@gmail.com>
Cc: Linus Torvalds <torvalds@linux-foundation.org>,
	Andrew Morton <akpm@linux-foundation.org>,
	linux-kernel@vger.kernel.org,
	Andreas Gruenbacher <agruen@suse.de>,
	Jeff Mahoney <jeffm@suse.de>
Subject: Re: [patch 00/04] RFC: Staging tree (drivers/staging)
Date: Wed, 24 Sep 2008 19:06:08 -0700	[thread overview]
Message-ID: <20080925020608.GA13869@suse.de> (raw)
In-Reply-To: <f7848160809241639hbe716c9q76b0e1b83d853721@mail.gmail.com>

On Wed, Sep 24, 2008 at 07:39:42PM -0400, Parag Warudkar wrote:
> On Wed, Sep 24, 2008 at 7:00 PM, Greg KH <gregkh@suse.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.)

No, this is much different from EXPERIMENTAL.  That flag is pretty much
useless right now.  This is for a temporary landing place for drivers
that are not good enough to be merged, yet are useful enough for some
people to use.

Examples of this is the USB driver I posted, some network drivers that
are in -staging that only work on x86 boxes, and drivers that have
userspace interfaces that are "wrong" and need to be changed (reading
files from /etc is one example.)

All of those types of drivers are not capable of being merged today, and
EXPERIMENTAL doesn't mean anything there.

Also, api changes do not have to propagate into the drivers/staging/
directory.  I'll work to keep up with them, keeping everything working
properly, just like I have been with the external -staging tree.  This
is just pushing it into the tree to give it much wider exposure and draw
from more developers makeing it easier to give them the proper credit
for this clean-up work.

> 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 .

Why, that word is only internal, nothing outside of the kernel sees that
flag at all, no user will ever know this.

And if we leave it as TAINT_CRAP, and a developer sees it, perhaps it
will cause them to make their code cleaner next time around :)

> 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.

I can easily add a "no_crap" flag to the command line.  Oops, there's
that word going out to userspace, how about "no_staging"?

> 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.

This keeps these kinds of drivers in one place, obvious to all that work
needs to be done, and userspace interfaces can, and usually will change
for such drivers.

I think the boat has left on making EXPERIMENTAL mean anything anymore,
but if you or anyone else wants to clean up the tree, and free it up,
then I would reconsider using it here instead.  But you can't start
making it something that means more than it does today, as I can easily
see that breaking systems that currently rely on those drivers.

thanks,

greg k-h

  parent reply	other threads:[~2008-09-25  2:08 UTC|newest]

Thread overview: 36+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <20080924224638.514504825@mini.kroah.org>
2008-09-24 23:00 ` [patch 00/04] RFC: Staging tree (drivers/staging) Greg KH
2008-09-24 23:01   ` [patch 01/04] Staging: add TAINT_CRAP for all drivers/staging code Greg KH
2008-09-24 23:01   ` [patch 02/04] Staging: add TAINT_CRAP flag to drivers/staging modules Greg KH
2008-09-24 23:01   ` [patch 04/04] USB: add princeton instruments usb camera driver Greg KH
2008-09-24 23:01   ` [patch 03/04] Staging: add Kconfig entries and Makefile infrastructure Greg KH
2008-09-24 23:39   ` [patch 00/04] RFC: Staging tree (drivers/staging) Parag Warudkar
2008-09-25  1:03     ` Randy Dunlap
2008-09-25  2:06       ` Greg KH
2008-09-25  2:06     ` Greg KH [this message]
2008-09-25  2:59       ` Parag Warudkar
2008-09-25  4:21         ` Greg KH
2008-09-25 11:02           ` Parag Warudkar
2008-09-25 20:53             ` Greg KH
2008-09-25 21:40               ` Parag Warudkar
2008-09-25 22:04                 ` Greg KH
2008-09-25 22:22                   ` Parag Warudkar
2008-09-26 18:36                     ` Stefan Richter
2008-09-26 20:11                       ` Parag Warudkar
2008-09-26 20:19                         ` Greg KH
2008-09-26 20:56                           ` Parag Warudkar
2008-09-26 22:03                             ` Greg KH
2008-09-26 21:00                           ` Leon Woestenberg
2008-09-26 22:04                             ` Greg KH
2008-09-26 20:39                         ` Stefan Richter
2008-09-26 20:47                           ` Parag Warudkar
2008-09-26 22:46                             ` Stefan Richter
2008-09-25  5:27         ` Paul Mundt
2008-09-25 14:49           ` Randy Dunlap
2008-09-25 17:53             ` Randy Dunlap
2008-09-25 20:48               ` Greg KH
2008-09-25 21:04                 ` Randy Dunlap
2008-09-25 21:51                   ` Stefan Richter
2008-10-06 15:11               ` config_experimental was " Pavel Machek
2008-10-09 21:01   ` Adrian Bunk
2008-10-09 21:08     ` Greg KH
2008-10-09 21:17     ` Andrew Morton

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=20080925020608.GA13869@suse.de \
    --to=gregkh@suse.de \
    --cc=agruen@suse.de \
    --cc=akpm@linux-foundation.org \
    --cc=jeffm@suse.de \
    --cc=linux-kernel@vger.kernel.org \
    --cc=parag.lkml@gmail.com \
    --cc=torvalds@linux-foundation.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