Re: [PATCH] net/, drivers/net/ , missing EXPERIMENTAL in menus

["Robert P. J. Day" <rpjday@mindspring.com>]

On Thu, 19 Jul 2007, Simon Arlott wrote:

> On 19/07/07 17:19, Robert P. J. Day wrote:
> > On Thu, 19 Jul 2007, Randy Dunlap wrote:
> >> I think that Stefan means a patch to the kconfig source code,
> >> not the the Kconfig files.  Good luck.  I'd still like to see it.
> >
> > yes, i understand what he wanted now.  as a first step (that
> > theoretically shouldn't change any behaviour), i'd patch the Kconfig
> > structure to add a new attribute ("maturity") which would be allowed
> > to be set to *exactly one* of a pre-defined set of values (say,
> > OBSOLETE, DEPRECATED, EXPERIMENTAL, and STILLBLEEDING).  and that's
> > it, nothing more.
> >
> > don't try to do anything with any of that just yet, just add the
> > infrastructure to support the (optional) association of a maturity
> > level with a config option.  that's step one.
>
> What about something like this? I'm not sure if the addition to sym_init
> is desirable... I also had to prefix _ to the name for now otherwise it
> conflicts badly with the current symbols. It probably should stop
> "depends on _BROKEN" etc. too.
>
> ---
> diff --git a/init/Kconfig b/init/Kconfig
> diff --git a/net/Kconfig b/net/Kconfig
> index cdba08c..5e2f4db 100644
> --- a/net/Kconfig
> +++ b/net/Kconfig
> @@ -6,6 +6,7 @@ menu "Networking"
>
>  config NET
>  	bool "Networking support"
> +	maturity _BROKEN

just as a bit of a digression, "BROKEN" is not what i would call a
maturity level, and i would explicitly *not* allow that as a possible
maturity because that just makes a mess of the design.

i specifically wanted to define a maturity level so that any feature
could be categorized as belonging to *at most* one maturity level.
that is, you can't be both EXPERIMENTAL and DEPRECATED at the same
time -- that just makes no sense.

once you tag some features with a maturity level, then part of the
build would involve selecting which subset of maturity levels you
wanted to see.  by default, you'd get to see those features that
weren't tagged at all, but you might also make a selection like this:

  [*] EXPERIMENTAL
  [*] DEPRECATED
  [ ] OBSOLETE

in other words, you wanted the choice of stuff in the first two
categories, but not the third.  (you would, of course, always get to
choose from non-tagged stuff, which would be your *normal* content,
exactly as it is now).

so what about BROKEN?  i would invent a whole new attribute for that,
called maybe "status":

config FUBAR
	depends on ...
	maturity DEPRECATED
	status BROKEN
	...

"status" is a totally orthogonal attribute to maturity.  status might
be one of BROKEN, BROKEN_ON_SMP, FLAKEY_AS HELL, etc.  and, once
again, any feature can fall into *at most* one status category.  once
you have the infrastructure to support a single attribute like
maturity, you get any additional ones for free.  and rather than
defining all those things as simple dependencies, by creating new
objects called "attributes", you can play all sorts of interesting new
games, and the attribute infrastructure can enforce that you're using
it properly.

now i'll go away and read the rest of your post.  :-)

rday

-- 
========================================================================
Robert P. J. Day
Linux Consulting, Training and Annoying Kernel Pedantry
Waterloo, Ontario, CANADA

http://fsdev.net/wiki/index.php?title=Main_Page
========================================================================
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/