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

On Wed, Jul 18, 2007 at 05:18:20PM -0400, Robert P. J. Day wrote:
On Wed, 18 Jul 2007, Adrian Bunk wrote:

On Wed, Jul 18, 2007 at 04:51:33PM -0400, Robert P. J. Day wrote:
On Wed, 18 Jul 2007, Jeff Garzik wrote:

Randy Dunlap wrote:
On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:
there's no point adding all that redundant content when it can all be
done automatically.

I like it. Are there any kconfig patches to support this plan?

Speaking specifically to adding 'EXPERIMENTAL', I distinctly
remember at some point in the past the config system was smart
enough to print " (EXPERIMENTAL)" if that entry depended on
CONFIG_EXPERIMENTAL.

We should head in that direction.

there's one point i want to re-iterate. i'd prefer to see
EXPERIMENTAL stop being a dependency, as in:

depends on SNAFU && FUBAR && EXPERIMENTAL

"EXPERIMENTAL" is not a dependency in the true sense of the word
-- it is more of an attribute, and i think it would far more sense
to see entries like:

depends on SNAFU && FUBAR
maturity EXPERIMENTAL

Plus some special case in the kconfig code that you can somewhere
select the maturity levels you want to use (currently it's a normal
option kconfig doesn't have to know anything about).

i already described that here:

http://readlist.com/lists/vger.kernel.org/linux-kernel/66/334172.html

where the top-level config would look something like:

[*] Activate maturity attributes
[*] EXPERIMENTAL
[*] DEPRECATED
[*] OBSOLETE
[*] BROKEN

We already made the mistake of offering BROKEN as an option in the past,
and the result was that people enabled it instead of reporting that a
dependency on BROKEN was wrong.

whereupon you could select any combination of the attributes you want
displayed *beyond the regular ones* during the config process.

Remind me, would there be any big advantage after such a change
besides being able to automatically print " (EXPERIMENTAL)" at the
end of the prompt?

defining a new Kconfig attribute means you can process it differently
from regular dependencies. and if it's added as a general feature, it
can be used for other possible attributes beyond just a maturity
level.

if you leave these maturity levels as regular dependencies, you're
going to have to brute force and manually process them, and why make
it that ugly?

I would consider it more ugly to special case this and that in the
kconfig code when plain dependencies already offer exactly the same
functionality...

rday

cu
Adrian

--

"Is there not promise of rain?" Ling Tan asked suddenly out
of the darkness. There had been need of rain for many days.
"Only a promise," Lao Er said.
Pearl S. Buck - Dragon Seed

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/

Relevant Pages