Messages in this thread | | | Date | Thu, 25 Sep 2008 14:27:26 +0900 | From | Paul Mundt <> | Subject | Re: [patch 00/04] RFC: Staging tree (drivers/staging) |
| |
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 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.
| |