linux-kernel - Re: [patch 00/04] RFC: Staging tree (drivers/staging)

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <f7848160809241959s3f3092b2nf05d2245a08bed03@mail.gmail.com>
Date:	Wed, 24 Sep 2008 22:59:03 -0400
From:	"Parag Warudkar" <parag.lkml@...il.com>
To:	"Greg KH" <gregkh@...e.de>
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 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.

You might try to differentiate between them on the basis of relative
brokenness or crappiness if you will - but it is essentially the same
- code that is not ideal for merge in mainline, code that needs user
testing to trash out problems, and code that need to be in sync with
mainline and code that users want to use in order to be able to use
their hardware. I fail to see how this is different at all.

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

I don't see a reason to further classify and label the experimental
code - it is experimental. That classification suffices.

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

Sure. Merge them under EXPERIMENTAL - may be with a big fat colored
KConfig warning about what is broken.
Tainting and labeling it staging does nothing of any value add. Sure
you can have a staging directory in the tree and dump all the
unmergeable code there if that gives a sense of isolation but I do not
see a point in letting users build the staging code, loading it
without their intervention and then printing a warning and tainting
the kernel.

So what if there is a oops report tomorrow and we know it is Tainted :
EXPERIMENTAL -  OOPS reports generally are very indicative of  where
the problem is coming from and the knowledge that certain broken
driver is loaded is just fine to be outside the kernel - no need for
the TAINT intimidation which drives away users from reporting it and
developers from addressing it.

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

There's the clue - this _will_ happen with staging - I can almost see it.
So why not do it under one existing monster of an umbrella - or do you
have plans to make sure you are not going to add a new staging driver
unless the existing ones graduate to stable? Even if you do -  doable
under EXPERIMENTAL.

Parag
--
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/