Messages in this thread | | | Date | Thu, 25 Sep 2008 07:49:23 -0700 | From | Randy Dunlap <> | 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@suse.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
| |