Date:	Thu, 25 Sep 2008 07:49:23 -0700
From:	Randy Dunlap <randy.dunlap@...cle.com>
To:	Paul Mundt <lethal@...ux-sh.org>
Cc:	Parag Warudkar <parag.lkml@...il.com>, Greg KH <gregkh@...e.de>,
	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, 25 Sep 2008 14:27:26 +0900 Paul Mundt wrote:

> On Wed, Sep 24, 2008 at 10:59:03PM -0400, Parag Warudkar wrote:
> > On Wed, Sep 24, 2008 at 10:06 PM, Greg KH <gregkh@...e.de> wrote:
> > > 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.
> > 
> > How? TAINT_EXPERIMENTAL (I'll stick to that, thanks :) and
> > CONFIG_EXPERIMENTAL are no different - neither to users nor to
> > developers. Here is why -
> > Both try to do the same thing - let people use the drivers on their
> > own risk (as if the stable ones are developer's risk - but let's keep
> > it aside for the moment) and give developers a chance to keep the code
> > in sync with mainline and improve it per user problem reports or
> > generally make it better.
> > 
> Uhm.. not quite. As the one that proposed the flag in the first place,
> perhaps it helps to cover the rationale (although Greg seems to have
> mostly covered that already).
> 
> EXPERIMENTAL today is pretty damn meaningless. What it tends to mean in

then it would be better if Greg/someone cleaned up the current tree's
problems instead of introducing more CRAP under a different name.
Oh well, his mind is already made up and I know how difficult it is to
change it.


> practice is that somethings needs some more testing, someone wants to be
> able to pull out the EXPERIMENTAL card when someone enables their option
> and their kernel blows up, the option/feature hasn't been around in the
> kernel for that long, or someone has just been too lazy to remove the
> flag (this last one probably covers about 90% of in-tree cases today).
> Stuff that is actively broken (in case of your kernel blowing up, not
> building, etc.) tends to be shoved under BROKEN instead.
> 
> Case in point:
> 
> 	$ find arch | grep _defconfig | wc -l
> 	336
> 	$ find arch | grep _defconfig | xargs grep 'CONFIG_EXPERIMENTAL=y' | wc -l
> 	324
> 	$ find arch | grep _defconfig | xargs grep 'CONFIG_BROKEN=y' | wc -l
> 	0
> 
> So given that, CONFIG_EXPERIMENTAL is something that's almost universally
> enabled, and has precisely _zero_ meaning. As others have mentioned in
> the past, it would be nice to try and audit each one of the EXPERIMENTAL
> users and try to get things under control a bit, so we can get back to a
> point where it actually means something, but we're definitely nowhere
> near that point today.
> 
> Now, TAINT_CRAP (other options were TAINT_INCOMPETENT_VENDOR and
> TAINT_GREG). This is something with a completely different meaning.
> staging/ drivers are there because there are users for these devices, and
> we actively want people looking at and cleaning up this code. As is
> evident by other proprietary driver usage statistics, it's evident that
> users will generally pick device functionality (whether perceived or
> otherwise) over system stability quite a lot of the time.
> 
> The stuff in this directory is by no means ready to be merged with the
> rest of the kernel, and is generally in pretty rough shape. While these
> drivers are generally audited to make sure they are not actively hostile
> to the system prior to being merged, they are still going to require
> heavy rewriting before the bugs get shaken out and it actually looks like
> kernel code. Vendor drivers will do such wonderful things as userspace
> file I/O (when they aren't busy doing active NULL pointer dereferences)
> from the kernel driver because that's what the windows driver did.
> EXPERIMENTAL doesn't even begin to cover it, this is simply crap.
> 
> The other key difference is that even with experimental stuff in the
> kernel, you will still get support, so it's not really a taintable
> offense. Stuff in staging/ on the other hand while potentially not
> actively hostile against the rest of the system, is still very much an
> unknown, and therefore the only safe thing to do is to taint the system
> and allow individual developers to make a choice regarding whether any
> resulting oopses are worth looking at or not.
> 
> Part of the benefits of staging/ is catching all of the one-shot patches
> that vendors toss out to meet their licensing requirements -- or so they
> can slap a Linux-friendly logo on their shrinkwrap, where there are
> already a good chunk of active users and folks interested in getting
> things cleaned up, long after the vendor has bailed. Doing this sort of
> work in-tree makes the most sense, as what's going on is immediately
> visible, and you get a lot more people testing and working on the driver
> in question. If we tried to force someone to make a sourceforge project
> for every abandoned vendor driver, we'd end up with some sort of
> wasteland of abandoned kernel code that looks something like, well,
> sourceforge. Doing this sort of work out-of-tree just isn't worth it. The
> staging/ tree has been doing well out-of-tree to date, but these sorts of
> things aren't going to get any real momentum without being integrated,
> with the users/developers and vendors forced to actually deal with the
> problem.
> --

---
~Randy
--
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