net/, drivers/net/ , missing EXPERIMENTAL in menus

Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus.

Quoted 2 lines · Gabriel C

Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus.

rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a "maturity level" attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation.

there's no point adding all that redundant content when it can all be done automatically.

Quoted 2 lines · 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?

Quoted 11 lines · On Wed, 18 Jul 2007 16:23:09 -0400 (EDT) Robert P. J. Day wrote:

Quoted 2 lines · Gabriel C

Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus.

rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a "maturity level" attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation.

Quoted 2 lines

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?

Quoted 2 lines · Gabriel C

Everything 'depends on' EXPERIMENTAL should be marked as such, visible in the menus.

rather than add all that extraneous dreck to the Kconfig files, i *really* wish folks would give serious thought to my earlier suggestion about a "maturity level" attribute that could be used to not only add a parenthesized maturity level during display, but could also be used to activate/deactivate entire levels in one operation.

there's no point adding all that redundant content when it can all be done automatically.

rday

Quoted 5 lines · Randy Dunlap

Quoted 2 lines · 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.

I strongly NAK the original patch from Gabriel C in this thread -- it just adds too much redundant info. Better to add it -once-, somewhere inside Kconfig system.

Jeff

Quoted 4 lines · Randy Dunlap

Quoted 2 lines · 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.

Quoted 1 line

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.

Quoted 5 lines · Jeff Garzik

Quoted 4 lines · Randy Dunlap

Quoted 2 lines · 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.

Quoted 8 lines

Quoted 1 line

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

sure, it's more work, but i think the cost is worth it in terms of flexibility (particularly if *i'm* not the one doing the work. :-)

rday

Quoted 25 lines · Robert P. J. Day

Quoted 5 lines · Jeff Garzik

Quoted 4 lines · Randy Dunlap

Quoted 2 lines · 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.

Quoted 8 lines

Quoted 1 line

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:

Quoted 2 lines

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

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?

If you are not doing it, noone might do it. And discusing improvements noone will implement is somehow pointless...

Quoted 26 lines · Adrian Bunk

Quoted 25 lines · Robert P. J. Day

Quoted 5 lines · Jeff Garzik

Quoted 4 lines · Randy Dunlap

Quoted 2 lines · 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.

Quoted 8 lines

Quoted 1 line

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:

Quoted 6 lines

Quoted 2 lines

  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

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

Quoted 3 lines

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?

rday

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

On Thu, 19 Jul 2007, Adrian Bunk wrote:

...

Quoted 3 lines

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

well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it.

Quoted 11 lines · Robert P. J. Day

On Thu, 19 Jul 2007, Adrian Bunk wrote:

...

Quoted 3 lines

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

well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it.

For better or worse, it can often be observed that feature requests don't set anything in motion until a first patch is sent. Even a patch that is far from perfect can get things going really quickly. (If the requested feature makes sense to other people.)

i *did* submit a preliminary patch once upon a time, and it (predictably) went nowhere.

Quoted 13 lines · Stefan Richter

Quoted 11 lines · Robert P. J. Day

On Thu, 19 Jul 2007, Adrian Bunk wrote:

...

Quoted 3 lines

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

well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it.

Quoted 4 lines

For better or worse, it can often be observed that feature requests don't set anything in motion until a first patch is sent. Even a patch that is far from perfect can get things going really quickly. (If the requested feature makes sense to other people.)

i *did* submit a preliminary patch once upon a time, and it (predictably) went nowhere. so, if someone else wants to pick this up and do something with it, you have my blessing. life's too short to keep wasting time on this.

Quoted 20 lines · On Thu, 19 Jul 2007 05:25:30 -0400 (EDT) Robert P. J. Day wrote:

Quoted 17 lines · Stefan Richter

Quoted 11 lines · Robert P. J. Day

On Thu, 19 Jul 2007, Adrian Bunk wrote:

...

Quoted 3 lines

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

well, this is the *third* time i've proposed adding this kind of feature so, at this point, i've really given up caring about it. if someone wants to do this, have at it. i have better things to do than to keep suggesting it and getting nowhere with it.

For better or worse, it can often be observed that feature requests don't set anything in motion until a first patch is sent. Even a patch that is far from perfect can get things going really quickly. (If the requested feature makes sense to other people.)

Quoted 4 lines

i *did* submit a preliminary patch once upon a time, and it (predictably) went nowhere. so, if someone else wants to pick this up and do something with it, you have my blessing. life's too short to keep wasting time on this.

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.

Quoted 2 lines · Randy Dunlap

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.

Quoted 11 lines · Robert P. J. Day

Quoted 2 lines · Randy Dunlap

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.

Quoted 3 lines

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.

---

init/Kconfig +0 -0

net/Kconfig +0 -0

index cdba08c..5e2f4db 100644

Quoted 11 lines · Robert P. J. Day

Quoted 2 lines · Randy Dunlap

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.

Quoted 3 lines

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.

---

init/Kconfig +0 -0

net/Kconfig +1 -0

index cdba08c..5e2f4db 100644
@@ -6,6 +6,7 @@ menu "Networking"
 
 config NET
 	bool "Networking support"
+	maturity _BROKEN
 	---help---
 	  Unless you really know what you are doing, you should say Y here.
 	  The reason is that some programs need kernel networking support even

net/ipv6/addrconf.c +0 -0

scripts/kconfig/Makefile +1 -1

index fb2bb30..1dea08e 100644
@@ -256,7 +256,7 @@ $(obj)/lkc_defs.h: $(src)/lkc_proto.h
 # The following requires flex/bison/gperf
 # By default we use the _shipped versions, uncomment the following line if
 # you are modifying the flex/bison src.
-# LKC_GENPARSER := 1
+LKC_GENPARSER := 1
 
 ifdef LKC_GENPARSER
 

scripts/kconfig/conf.c +16 -0

index 1199baf..cc9be0e 100644
@@ -211,6 +211,22 @@ static int conf_sym(struct menu *menu)
 
 	while (1) {
 		printf("%*s%s ", indent - 1, "", menu->prompt->text);
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			printf("(EXPERIMENTAL) ");
+			break;
+		case M_DEPRECATED:
+			printf("(DEPRECATED) ");
+			break;
+		case M_OBSOLETE:
+			printf("(OBSOLETE) ");
+			break;
+		case M_BROKEN:
+			printf("(BROKEN) ");
+			break;
+		default:
+			break;
+		}
 		if (sym->name)
 			printf("(%s) ", sym->name);
 		type = sym_get_type(sym);

scripts/kconfig/expr.h +1 -1

index 6084525..a22b6c1 100644
@@ -60,7 +60,11 @@ struct symbol_value {
 };
 
 enum symbol_type {
-	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_OTHER
+	S_UNKNOWN, S_BOOLEAN, S_TRISTATE, S_INT, S_HEX, S_STRING, S_MATURITY,

S_OTHER

scripts/kconfig/expr.h +5 -0

+};
+
+enum maturity_level {
+	M_NONE, M_EXPERIMENTAL, M_DEPRECATED, M_OBSOLETE, M_BROKEN
 };
 
 enum {

@@ -72,6 +76,7 @@ struct symbol {
 	struct symbol *next;
 	char *name;
 	char *help;
+	enum maturity_level maturity;
 	enum symbol_type type;
 	struct symbol_value curr;
 	struct symbol_value def[4];

scripts/kconfig/lex.zconf.c_shipped +0 -0

scripts/kconfig/lkc.h +1 -0

index 8a07ee4..9add1cd 100644
@@ -79,6 +79,7 @@ void menu_end_menu(void);
 void menu_add_entry(struct symbol *sym);
 void menu_end_entry(void);
 void menu_add_dep(struct expr *dep);
+void menu_set_maturity(struct symbol *sym);
 struct property *menu_add_prop(enum prop_type type, char *prompt,
 struct expr *expr, struct expr *dep);
 struct property *menu_add_prompt(enum prop_type type, char *prompt,

struct expr *dep);
void menu_add_expr(enum prop_type type, struct expr *expr, struct expr
*dep);

scripts/kconfig/mconf.c +22 -0

index d0e4fa5..eaf199b 100644
@@ -238,6 +238,7 @@ search_help[] = N_(
 	"Result:\n"
 	"-----------------------------------------------------------------\n"
 	"Symbol: FOO [=m]\n"
+	"Maturity: FOO\n"
 	"Prompt: Foo bus is used to drive the bar HW\n"
 	"Defined at drivers/pci/Kconfig:47\n"
 	"Depends on: X86_LOCAL_APIC && X86_IO_APIC || IA64\n"

@@ -359,6 +360,27 @@ static void get_symbol_str(struct gstr *r, struct
 symbol *sym)
 
 	str_printf(r, "Symbol: %s [=%s]\n", sym->name,
 	                               sym_get_string_value(sym));
+
+	if (sym->maturity != M_NONE) {
+		str_append(r, "Maturity: ");
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			str_append(r, "EXPERIMENTAL\n");
+			break;
+		case M_DEPRECATED:
+			str_append(r, "DEPRECATED\n");
+			break;
+		case M_OBSOLETE:
+			str_append(r, "OBSOLETE\n");
+			break;
+		case M_BROKEN:
+			str_append(r, "BROKEN\n");
+			break;
+		default:
+			break;
+		}
+	}
+
 	for_all_prompts(sym, prop)
 		get_prompt_str(r, prop);

scripts/kconfig/mconf.c +0 -0

 	hit = false;

scripts/kconfig/menu.c +9 -0

index f14aeac..3e37e5b 100644
@@ -104,6 +104,15 @@ void menu_add_dep(struct expr *dep)
 	current_entry->dep = expr_alloc_and(current_entry->dep,
 menu_check_dep(dep));
 }
 
+void menu_set_maturity(struct symbol *sym)
+{
+	if (sym->type != S_MATURITY) {
+		zconf_error("'%s' is an invalid maturity level", sym->name);
+	} else {
+		current_entry->sym->maturity = sym->maturity;
+	}
+}
+
 void menu_set_type(int type)
 {

scripts/kconfig/menu.c +0 -0

 	struct symbol *sym = current_entry->sym;

scripts/kconfig/symbol.c +19 -0

index c35dcc5..280ee8f 100644
@@ -72,6 +72,22 @@ void sym_init(void)
 	sym->type = S_STRING;
 	sym->flags |= SYMBOL_AUTO;
 	sym_add_default(sym, uts.release);
+
+	sym = sym_lookup("_EXPERIMENTAL", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_EXPERIMENTAL;
+
+	sym = sym_lookup("_DEPRECATED", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_DEPRECATED;
+
+	sym = sym_lookup("_OBSOLETE", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_OBSOLETE;
+
+	sym = sym_lookup("_BROKEN", 0);
+	sym->type = S_MATURITY;
+	sym->maturity = M_BROKEN;
 }
 
 enum symbol_type sym_get_type(struct symbol *sym)

@@ -100,6 +116,8 @@ const char *sym_type_name(enum symbol_type type)
 		return "hex";
 	case S_STRING:
 		return "string";
+	case S_MATURITY:
+		return "maturity";
 	case S_UNKNOWN:
 		return "unknown";
 	case S_OTHER:

@@ -679,6 +697,7 @@ struct symbol *sym_lookup(const char *name, int isconst)
 	memset(symbol, 0, sizeof(*symbol));
 	symbol->name = new_name;
 	symbol->type = S_UNKNOWN;
+	symbol->maturity = M_NONE;
 	if (isconst)
 		symbol->flags |= SYMBOL_CONST;
 

scripts/kconfig/zconf.gperf +1 -0

index 9b44c80..756d559 100644
@@ -25,6 +25,7 @@ endif,		T_ENDIF,	TF_COMMAND
 depends,	T_DEPENDS,	TF_COMMAND
 requires,	T_REQUIRES,	TF_COMMAND
 optional,	T_OPTIONAL,	TF_COMMAND
+maturity,	T_MATURITY,	TF_COMMAND
 default,	T_DEFAULT,	TF_COMMAND, S_UNKNOWN
 prompt,		T_PROMPT,	TF_COMMAND
 tristate,	T_TYPE,		TF_COMMAND, S_TRISTATE

scripts/kconfig/zconf.y +1 -1

index 92eb02b..1b47966 100644
@@ -66,6 +66,7 @@ static struct menu *current_menu, *current_entry;
 %token <id>T_DEPENDS
 %token <id>T_REQUIRES
 %token <id>T_OPTIONAL
+%token <id>T_MATURITY
 %token <id>T_PROMPT
 %token <id>T_TYPE
 %token <id>T_DEFAULT

@@ -120,7 +121,7 @@ stmt_list:
 ;
 
 option_name:
-	T_DEPENDS | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL | T_RANGE |

T_DEFAULT

scripts/kconfig/zconf.y +1 -0

+	T_DEPENDS | T_MATURITY | T_PROMPT | T_TYPE | T_SELECT | T_OPTIONAL |

T_RANGE | T_DEFAULT
;

common_stmt:

scripts/kconfig/zconf.y +20 -1

@@ -177,6 +178,7 @@ config_option_list:
 	| config_option_list config_option
 	| config_option_list symbol_option
 	| config_option_list depends
+	| config_option_list maturity
 	| config_option_list help
 	| config_option_list option_error
 	| config_option_list T_EOL

@@ -269,6 +271,7 @@ choice_option_list:
 	  /* empty */
 	| choice_option_list choice_option
 	| choice_option_list depends
+	| choice_option_list maturity
 	| choice_option_list help
 	| choice_option_list T_EOL
 	| choice_option_list option_error

@@ -349,7 +352,7 @@ menu: T_MENU prompt T_EOL
 	printd(DEBUG_PARSE, "%s:%d:menu\n", zconf_curname(), zconf_lineno());
 };
 
-menu_entry: menu depends_list
+menu_entry: menu maturity_set_opt depends_list
 {
 	$$ = menu_add_menu();
 };

@@ -430,6 +433,19 @@ depends: T_DEPENDS T_ON expr T_EOL
 	printd(DEBUG_PARSE, "%s:%d:requires\n", zconf_curname(), zconf_lineno());
 };
 
+/* maturity setting */
+
+maturity_set_opt:
+	  /* empty */
+	| maturity
+;
+
+maturity: T_MATURITY symbol T_EOL
+{
+	menu_set_maturity($2);
+	printd(DEBUG_PARSE, "%s:%d:maturity\n", zconf_curname(), zconf_lineno());
+};
+
 /* prompt statement */
 
 prompt_stmt_opt:

@@ -519,6 +535,7 @@ const char *zconf_tokenname(int token)
 	case T_IF:		return "if";
 	case T_ENDIF:		return "endif";
 	case T_DEPENDS:		return "depends";
+	case T_MATURITY:	return "maturity";
 	}
 	return "<token>";
 }

@@ -615,6 +632,9 @@ void print_symbol(FILE *out, struct menu *menu)
 	case S_HEX:
 		fputs("  hex\n", out);
 		break;
+	case S_MATURITY:
+		fputs("  maturity\n", out);
+		break;
 	default:
 		fputs("  ???\n", out);
 		break;

Signature · 1 line

-- 

Quoted 12 lines · On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

Quoted 11 lines · Robert P. J. Day

Quoted 2 lines · Randy Dunlap

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.

Quoted 8 lines

Quoted 3 lines

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.

Quoted 13 lines · Randy Dunlap

Quoted 11 lines · On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

Quoted 10 lines · Robert P. J. Day

Quoted 2 lines · Randy Dunlap

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.

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

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.

i'm sure i'm going to get shouted down here, but i really disagree with "BROKEN" being considered a "maturity level". IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons.

something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in.

Quoted 5 lines

something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level. A more accurate description would be BITROTTING perhaps. The code in question has passed through bleeding -> experimental -> stable, and come out the other side.

Quoted 28 lines · Robert P. J. Day

Quoted 13 lines · Randy Dunlap

Quoted 11 lines · On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

Quoted 10 lines · Robert P. J. Day

Quoted 2 lines · Randy Dunlap

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.

Quoted 7 lines

Quoted 7 lines

Quoted 3 lines

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.

i'm sure i'm going to get shouted down here, but i really disagree with "BROKEN" being considered a "maturity level". IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons.

Quoted 5 lines

something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level. A more accurate description would be BITROTTING perhaps. The code in question has passed through bleeding -> experimental -> stable, and come out the other side.

In contrast, OBSOLETE and DEPRECATED reflect high-level status not code quality/maturity.

Quoted 5 lines · Robert P. J. Day

i'm sure i'm going to get shouted down here, but i really disagree with "BROKEN" being considered a "maturity level". IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons.

Quoted 6 lines

something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level.

In contrast, OBSOLETE and DEPRECATED reflect high-level status not code quality/maturity.

What I like about the patch is that it associates some kconfig symbol with prompt strings, so that we don't have to edit "(EXPERIMENTAL)" all the darn time (e.g.).

I'd be quite happy with calling it "status" rather than "maturity", and with being able to use multiple of the status tags at one time, such as

config FOO
depends on BAR
status OBSOLETE BROKEN

Quoted 11 lines · Randy Dunlap

What I like about the patch is that it associates some kconfig symbol with prompt strings, so that we don't have to edit "(EXPERIMENTAL)" all the darn time (e.g.).

I'd be quite happy with calling it "status" rather than "maturity", and with being able to use multiple of the status tags at one time, such as

config FOO
depends on BAR
status OBSOLETE BROKEN

grrrrrrrr ... i already made my point in my earlier post. i'd really, really like it if *this* attribute remained as "maturity". an entirely *separate* attribute could be defined as a feature "status", which would be entirely orthogonal to maturity level, so that the above would be written as

maturity OBSOLETE
status BROKEN

there's a reason for this -- any feature should have exactly *one* value for any attribute. that is, in terms of maturity, a feature could be EXPERIMENTAL *or* DEPRECATED *or* OBSOLETE. it ***can't*** be more than one, as in both DEPRECATED *and* OBSOLETE. to allow that flexibility is to descend into absurdity.

Quoted 7 lines · Jeff Garzik

Quoted 5 lines · Robert P. J. Day

i'm sure i'm going to get shouted down here, but i really disagree with "BROKEN" being considered a "maturity level". IMHO, things like EXPERIMENTAL, DEPRECATED and OBSOLETE represent maturity levels, for what i think are obvious reasons.

Quoted 7 lines

Quoted 6 lines

something like BROKEN, though, has *nothing* to do with maturity. a feature can be any of those maturity levels, and simultaneously be BROKEN. i consider BROKEN to be what i call a "status", and different status levels might be the default of normal, or KIND_OF_FLAKY or TOTALLY_BORKED -- that's where BROKEN would fit in.

BROKEN is definitely a maturity level.

no. it's not. end of discussion. you're wrong.

the concept of "maturity level" reflects where in the life cycle some feature is. it will typically start as "bleeding edge" or "experimental" or something like that, eventually stabilize to be normal (which would be the obvious default), after which, when its value starts to run out and it begins showing its age, it becomes "deprecated" and eventually "obsolete" it's a natural and obvious progression.

on the other hand, a feature can be "broken" at *any* point in that life cycle -- that's why it is absolutely *not* a maturity level. please don't fight with me on this, jeff. you're simply wrong.

'deprecrated' and 'obsolete' are matters of discussed opinion, describing the utility of the code in question. 'broken' describes the state of the code itself.

Clear difference.

Quoted 4 lines · On Thu, 19 Jul 2007 23:05:57 +0100 Simon Arlott wrote:

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.

Hi Simon,

(sorry for the delay)

I like this patch very much... I just can't get it to build (on 2.6.23-rc4).

Quoted 13 lines

scripts/kconfig/conf.c +11 -0

 	while (1) {
 		printf("%*s%s ", indent - 1, "", menu->prompt->text);
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			printf("(EXPERIMENTAL) ");
+			break;
+		case M_DEPRECATED:
+			printf("(DEPRECATED) ");
+			break;
+		case M_OBSOLETE:
+			printf("(OBSOLETE) ");
+			break;
+		case M_BROKEN:

scripts/kconfig/conf.c static int conf_sym(struct menu *menu) · line 232

Quoted 8 lines

scripts/kconfig/conf.c +5 -0

+			printf("(BROKEN) ");
+			break;
+		default:
+			break;
+		}
 		if (sym->name)
 			printf("(%s) ", sym->name);
 		type = sym_get_type(sym);

Quoted 17 lines

Quoted 17 lines

scripts/kconfig/conf.c +14 -0

 	while (1) {
 		printf("%*s%s ", indent - 1, "", menu->prompt->text);
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			printf("(EXPERIMENTAL) ");
+			break;
+		case M_DEPRECATED:
+			printf("(DEPRECATED) ");
+			break;
+		case M_OBSOLETE:
+			printf("(OBSOLETE) ");
+			break;
+		case M_BROKEN:
+			printf("(BROKEN) ");
+			break;
+		default:

Quoted 5 lines

scripts/kconfig/conf.c static int conf_sym(struct menu *menu) · line 232

Quoted 5 lines

scripts/kconfig/conf.c +2 -0

+			break;
+		}
 		if (sym->name)
 			printf("(%s) ", sym->name);
 		type = sym_get_type(sym);

for now, simon, why not just reduce this to supporting only DEPRECATED and OBSOLETE so that it can be at least tested as "proof of concept?"

Quoted 17 lines · Robert P. J. Day

Quoted 17 lines

Quoted 17 lines

scripts/kconfig/conf.c +14 -0

 	while (1) {
 		printf("%*s%s ", indent - 1, "", menu->prompt->text);
+		switch (sym->maturity) {
+		case M_EXPERIMENTAL:
+			printf("(EXPERIMENTAL) ");
+			break;
+		case M_DEPRECATED:
+			printf("(DEPRECATED) ");
+			break;
+		case M_OBSOLETE:
+			printf("(OBSOLETE) ");
+			break;
+		case M_BROKEN:
+			printf("(BROKEN) ");
+			break;
+		default:

Quoted 8 lines

Quoted 5 lines

scripts/kconfig/conf.c static int conf_sym(struct menu *menu) · line 232

Quoted 5 lines

scripts/kconfig/conf.c +2 -0

+			break;
+		}
 		if (sym->name)
 			printf("(%s) ", sym->name);
 		type = sym_get_type(sym);

for now, simon, why not just reduce this to supporting only DEPRECATED and OBSOLETE so that it can be at least tested as "proof of concept?"

The principle with letting a dependency add text to the promts are good. But the implementation done by Simon with a language extension is not good. A simple and better approach would be to use the newly added option support for this and let the backend generate the promtps.

I have not yet tried to cook up a patch for it, but it should be quite generaic and doable.

config EXPERIMENTAL
option appendprompt=" (EXPERIMENTAL)

config DEPRECATED
option appendprompt=" (DEPRECATED)