(no subject)

[Yann E. MORIN]

Michal, All,

This patch series:
  - includes a fix in case the user has CONFIG_ set in the environment
  - allows one to set a custom root-menu label, the same way we handle
    the CONFIG_ prefix

Regards,
Yann E. MORIN.

[PATCH 1/3] scripts/kconfig: ensure we use proper CONFIG_ prefix

[Yann E. MORIN]

Now that we get the CONFIG_ prefix from the environment, we must
ensure we use the proper prefix in case the user has it set in
the environment.

Simply unexport CONFIG_ to fallback to our hard-coded default.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 scripts/kconfig/Makefile |    3 +++
 1 files changed, 3 insertions(+), 0 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 3091794..231b475 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -11,6 +11,9 @@ else
 Kconfig := Kconfig
 endif
 
+# We need this, in case the user has it in its environment
+unexport CONFIG_
+
 xconfig: $(obj)/qconf
 	$< $(Kconfig)
 
-- 
1.7.2.5

Re: [PATCH 1/3] scripts/kconfig: ensure we use proper CONFIG_ prefix

[Michal Marek]

On Thu, Nov 22, 2012 at 01:06:04AM +0100, Yann E. MORIN wrote:
> Now that we get the CONFIG_ prefix from the environment, we must
> ensure we use the proper prefix in case the user has it set in
> the environment.
> 
> Simply unexport CONFIG_ to fallback to our hard-coded default.
> 
> Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>

Sorry for the delay. I applied this patch, so that the $CONFIG_ patches
do not cause any breakage in 3.8-rc1. We can discuss later if / how to
change it to use some Kconfig syntax instead.

Michal

Re: [PATCH 1/3] scripts/kconfig: ensure we use proper CONFIG_ prefix

[Yann E. MORIN]

Michal, All,

On Thursday 20 December 2012 Michal Marek wrote:
> On Thu, Nov 22, 2012 at 01:06:04AM +0100, Yann E. MORIN wrote:
> > Now that we get the CONFIG_ prefix from the environment, we must
> > ensure we use the proper prefix in case the user has it set in
> > the environment.
> > 
> > Simply unexport CONFIG_ to fallback to our hard-coded default.
> > 
> > Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
> 
> Sorry for the delay. I applied this patch, so that the $CONFIG_ patches
> do not cause any breakage in 3.8-rc1. We can discuss later if / how to
> change it to use some Kconfig syntax instead.

Ok, no problem! :-)

Of course, you can then forget about the first patch in the pull-request
I sent a few minutes ago. ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

[PATCH 2/3] scripts/kconfig: constify an argument

[Yann E. MORIN]

There is no reason for the prompt argument to be non-const, as it
can deal with const objects (eg. hard-coded root-menu label).

Furthermore, the next commit will also introduce another source
for the root-menu label, which will be explicitly marked const.

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 scripts/kconfig/lkc.h  |    4 ++--
 scripts/kconfig/menu.c |    4 ++--
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index f8aee5f..5cfd940 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -111,8 +111,8 @@ void menu_add_entry(struct symbol *sym);
 void menu_end_entry(void);
 void menu_add_dep(struct expr *dep);
 void menu_add_visibility(struct expr *dep);
-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);
+struct property *menu_add_prop(enum prop_type type, const char *prompt, struct expr *expr, struct expr *dep);
+struct property *menu_add_prompt(enum prop_type type, const char *prompt, struct expr *dep);
 void menu_add_expr(enum prop_type type, struct expr *expr, struct expr *dep);
 void menu_add_symbol(enum prop_type type, struct symbol *sym, struct expr *dep);
 void menu_add_option(int token, char *arg);
diff --git a/scripts/kconfig/menu.c b/scripts/kconfig/menu.c
index 84a2ba2..6175ead 100644
--- a/scripts/kconfig/menu.c
+++ b/scripts/kconfig/menu.c
@@ -124,7 +124,7 @@ void menu_set_type(int type)
 	    sym_type_name(sym->type), sym_type_name(type));
 }
 
-struct property *menu_add_prop(enum prop_type type, char *prompt, struct expr *expr, struct expr *dep)
+struct property *menu_add_prop(enum prop_type type, const char *prompt, struct expr *expr, struct expr *dep)
 {
 	struct property *prop = prop_alloc(type, current_entry->sym);
 
@@ -161,7 +161,7 @@ struct property *menu_add_prop(enum prop_type type, char *prompt, struct expr *e
 	return prop;
 }
 
-struct property *menu_add_prompt(enum prop_type type, char *prompt, struct expr *dep)
+struct property *menu_add_prompt(enum prop_type type, const char *prompt, struct expr *dep)
 {
 	return menu_add_prop(type, prompt, NULL, dep);
 }
-- 
1.7.2.5

[PATCH 3/3] scripts/kconfig: allow setting the root-menu label from environment

[Yann E. MORIN]

Currently, the root-menu label is hard-coded in the kconfig frontends
executables. This means that two projects that use kconfig and want
to display different root-menu labels can not share the same kconfig
frontends.

Instead of hard-coding the label in the frontends, handle it the same
we handle the CONFIG_ prefix:
  - get the root-menu label from the environment if present
  - allow to set it at build time (eg. -DROOTMENU='"Root menu label"')
  - fallback to a hard-coded default

(Note: the kconfig 'mainmenu' directive still has precedence)

(refresh zconf.tab.c_shipped to match)

Signed-off-by: "Yann E. MORIN" <yann.morin.1998@free.fr>
---
 scripts/kconfig/Makefile            |    3 ++-
 scripts/kconfig/lkc.h               |    8 ++++++++
 scripts/kconfig/zconf.tab.c_shipped |    2 +-
 scripts/kconfig/zconf.y             |    2 +-
 4 files changed, 12 insertions(+), 3 deletions(-)

diff --git a/scripts/kconfig/Makefile b/scripts/kconfig/Makefile
index 231b475..493da53 100644
--- a/scripts/kconfig/Makefile
+++ b/scripts/kconfig/Makefile
@@ -11,8 +11,9 @@ else
 Kconfig := Kconfig
 endif
 
-# We need this, in case the user has it in its environment
+# We need these, in case the user has them in its environment
 unexport CONFIG_
+unexport CONFIG_ROOTMENU
 
 xconfig: $(obj)/qconf
 	$< $(Kconfig)
diff --git a/scripts/kconfig/lkc.h b/scripts/kconfig/lkc.h
index 5cfd940..93b9e69 100644
--- a/scripts/kconfig/lkc.h
+++ b/scripts/kconfig/lkc.h
@@ -46,6 +46,14 @@ static inline const char *CONFIG_prefix(void)
 #undef CONFIG_
 #define CONFIG_ CONFIG_prefix()
 
+#ifndef CONFIG_ROOTMENU
+#define CONFIG_ROOTMENU "Linux Kernel Configuration"
+#endif
+static inline const char *CONFIG_rootmenu(void)
+{
+	return getenv( "CONFIG_ROOTMENU" ) ?: CONFIG_ROOTMENU;
+}
+
 #define TF_COMMAND	0x0001
 #define TF_PARAM	0x0002
 #define TF_OPTION	0x0004
diff --git a/scripts/kconfig/zconf.tab.c_shipped b/scripts/kconfig/zconf.tab.c_shipped
index f636141..8c91e69 100644
--- a/scripts/kconfig/zconf.tab.c_shipped
+++ b/scripts/kconfig/zconf.tab.c_shipped
@@ -2259,7 +2259,7 @@ void conf_parse(const char *name)
 	modules_sym = sym_lookup(NULL, 0);
 	modules_sym->type = S_BOOLEAN;
 	modules_sym->flags |= SYMBOL_AUTO;
-	rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+	rootmenu.prompt = menu_add_prompt(P_MENU, CONFIG_rootmenu(), NULL);
 
 	if (getenv("ZCONF_DEBUG"))
 		zconfdebug = 1;
diff --git a/scripts/kconfig/zconf.y b/scripts/kconfig/zconf.y
index 864da07..9ce6935 100644
--- a/scripts/kconfig/zconf.y
+++ b/scripts/kconfig/zconf.y
@@ -496,7 +496,7 @@ void conf_parse(const char *name)
 	modules_sym = sym_lookup(NULL, 0);
 	modules_sym->type = S_BOOLEAN;
 	modules_sym->flags |= SYMBOL_AUTO;
-	rootmenu.prompt = menu_add_prompt(P_MENU, "Linux Kernel Configuration", NULL);
+	rootmenu.prompt = menu_add_prompt(P_MENU, CONFIG_rootmenu(), NULL);
 
 	if (getenv("ZCONF_DEBUG"))
 		zconfdebug = 1;
-- 
1.7.2.5

Re: [PATCH 3/3] scripts/kconfig: allow setting the root-menu label from environment

[Sam Ravnborg]

Hi Yann.

On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote:
> Currently, the root-menu label is hard-coded in the kconfig frontends
> executables. This means that two projects that use kconfig and want
> to display different root-menu labels can not share the same kconfig
> frontends.
> 
> Instead of hard-coding the label in the frontends, handle it the same
> we handle the CONFIG_ prefix:
>   - get the root-menu label from the environment if present
>   - allow to set it at build time (eg. -DROOTMENU='"Root menu label"')
>   - fallback to a hard-coded default

I have note paid attention to these CONFIG_ patches - and only now
I took a short look at this set and I am not soo hapy
that we start to introduce a lot a environment variables for all this stuff.

(A lot in this context is two).

Could we instead introduce two reserved symbols like this:

config KCONFIG_ROOT_MENU
	string
	default "My own super duper root menu"

config KCONFIG_SYMBOL_PREFIX
	string
	default "SAM_"

the the configuration is included in the kconfig files,
and not something you need to set in the environment.

We already so something remotely like this for SYMBOLS
where one can define:

config MY_SYMBOLS
	option modules

Then MY_SYMBOLS in used as replacement for SYMBOLS

I did not implement this - but it looks sufficiently simple
to warrant getting rid on the dependency on the enviromnet variables.

	Sam

Re: [PATCH 3/3] scripts/kconfig: allow setting the root-menu label from environment

[Yann E. MORIN]

Sam, All,

On Friday 23 November 2012 Sam Ravnborg wrote:
> On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote:
> > Currently, the root-menu label is hard-coded in the kconfig frontends
> > executables. This means that two projects that use kconfig and want
> > to display different root-menu labels can not share the same kconfig
> > frontends.
> > 
> > Instead of hard-coding the label in the frontends, handle it the same
> > we handle the CONFIG_ prefix:
> >   - get the root-menu label from the environment if present
> >   - allow to set it at build time (eg. -DROOTMENU='"Root menu label"')
> >   - fallback to a hard-coded default
> 
> I have note paid attention to these CONFIG_ patches - and only now
> I took a short look at this set and I am not soo hapy
> that we start to introduce a lot a environment variables for all this stuff.
> 
> (A lot in this context is two).

Note that we already make heavy use of environment variables in the kconfig
frontends; from Documentation/kbuild/kconfig.txt:
    KCONFIG_ALLCONFIG
    KCONFIG_AUTOCONFIG
    KCONFIG_AUTOHEADER
    KCONFIG_CONFIG
    KCONFIG_NOSILENTUPDATE
    KCONFIG_OVERWRITECONFIG
    KCONFIG_TRISTATE

They are all prefixed with KCONFIG_, which I did not do in my submission,
because:
  - for CONFIG_, we already used a macro named CONFIG_, and I just
    reproduced that
  - for CONFIG_ROOTMENU, I just mimicked CONFIG_ and appended ROOTMENU

Obviously, CONFIG_ and CONFIG_ROOTMENU should be renamed, if we eventually
want to keep them:
  - CONFIG_          -->  KCONFIG_CONFIG_   or KCONFIG_CONFIG_PREFIX ?
  - CONFIG_ROOTMENU  -->  KCONFIG_ROOTMENU

Note: I missed updating the Documentation with these two new variables.

> Could we instead introduce two reserved symbols like this:
> 
> config KCONFIG_ROOT_MENU
> 	string
> 	default "My own super duper root menu"

For the root-menu label, no need to add such a specific symbol, as
we already have the 'mainmenu' directive that sets the root-menu
label, eg.:
    mainmenu "My own super duper root menu"

> config KCONFIG_SYMBOL_PREFIX
> 	string
> 	default "SAM_"

I am a bit uneasy adding magic in the kconfig language to drive the
behavior of the frontends.

To me, it makes more sense to drive the frontends using environment
variables.

> We already so something remotely like this for SYMBOLS
> where one can define:
> 
> config MY_SYMBOLS
> 	option modules
> 
> Then MY_SYMBOLS in used as replacement for SYMBOLS

You mean, for MODULES?

There's also DEFCONFIG_LIST.

> I did not implement this - but it looks sufficiently simple
> to warrant getting rid on the dependency on the enviromnet variables.

We already have 7 environment variables. That's just two more of them.

Anyway, I'll rework the series:
  - fix the variables names
  - add documentation

I'll also tackle this using config symbols instead.

Michal, now you have applied the CONFIG_ patches, what should I do to
rename it, so it is prefixed with KCONFIG_:
  - prepare a patch on your kconuild/kconfig branch, or
  - resubmit a complete series, that you'll apply after you trim the
    already applied changes?

What name would you prefer to rename CONFIG_ to:
  - KCONFIG_CONFIG_, or
  - KCONFIG_CONFIG_PREFIX?

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'

Re: [PATCH 3/3] scripts/kconfig: allow setting the root-menu label from environment

[Sam Ravnborg]

On Fri, Nov 23, 2012 at 10:21:44PM +0100, Yann E. MORIN wrote:
> Sam, All,
> 
> On Friday 23 November 2012 Sam Ravnborg wrote:
> > On Thu, Nov 22, 2012 at 01:06:06AM +0100, Yann E. MORIN wrote:
> > > Currently, the root-menu label is hard-coded in the kconfig frontends
> > > executables. This means that two projects that use kconfig and want
> > > to display different root-menu labels can not share the same kconfig
> > > frontends.
> > > 
> > > Instead of hard-coding the label in the frontends, handle it the same
> > > we handle the CONFIG_ prefix:
> > >   - get the root-menu label from the environment if present
> > >   - allow to set it at build time (eg. -DROOTMENU='"Root menu label"')
> > >   - fallback to a hard-coded default
> > 
> > I have note paid attention to these CONFIG_ patches - and only now
> > I took a short look at this set and I am not soo hapy
> > that we start to introduce a lot a environment variables for all this stuff.
> > 
> > (A lot in this context is two).
> 
> Note that we already make heavy use of environment variables in the kconfig
> frontends; from Documentation/kbuild/kconfig.txt:
>     KCONFIG_ALLCONFIG
>     KCONFIG_AUTOHEADER
>     KCONFIG_NOSILENTUPDATE
>     KCONFIG_OVERWRITECONFIG

Common for all of these is that they change the behaviour of the fronendts
concerning their inputs etc.
But none of them change the behaviour so the output become useless.
Also common for these is that they are optional.
If they are not specified kconfig will work as usual and the generated
output will be just fine.

>     KCONFIG_CONFIG
>     KCONFIG_AUTOCONFIG
>     KCONFIG_TRISTATE

These are used for non-default file loactions...

> > Could we instead introduce two reserved symbols like this:
> > 
> > config KCONFIG_ROOT_MENU
> > 	string
> > 	default "My own super duper root menu"
> 
> For the root-menu label, no need to add such a specific symbol, as
> we already have the 'mainmenu' directive that sets the root-menu
> label, eg.:
>     mainmenu "My own super duper root menu"

Had forgoten about this - why is it that we do not use this, but invent
an environment variable?


> 
> > config KCONFIG_SYMBOL_PREFIX
> > 	string
> > 	default "SAM_"
> 
> I am a bit uneasy adding magic in the kconfig language to drive the
> behavior of the frontends.
> 
> To me, it makes more sense to drive the frontends using environment
> variables.

Using magic kconfig symbols to decide for core functionality is IMO
a nice way to do so. I never liked (and still do not like) how environment
variables are used to adjust the front-end behaviour.
The real reason why we use environment variables is that we cannot
specify options for kconfig when we invoke make.

I long time ago played with the though that the kernel build should
be started with a shell script named "kbuild" to give us this added flexibility.
But I gave up as I back then did not have any real good reason to do so.

	Sam

Re: [PATCH 3/3] scripts/kconfig: allow setting the root-menu label from environment

[Yann E. MORIN]

Sam, Michal, All,

Sam, see my comments in-lined below.
Michal, there are a bunch of questions for you toward the end.
Others: your feedback is also most welcome! ;-)

On Sunday 25 November 2012 Sam Ravnborg wrote:
> On Fri, Nov 23, 2012 at 10:21:44PM +0100, Yann E. MORIN wrote:
> > On Friday 23 November 2012 Sam Ravnborg wrote:
[--SNIP--]
> > > Could we instead introduce two reserved symbols like this:
> > > 
> > > config KCONFIG_ROOT_MENU
> > > 	string
> > > 	default "My own super duper root menu"
> > 
> > For the root-menu label, no need to add such a specific symbol, as
> > we already have the 'mainmenu' directive that sets the root-menu
> > label, eg.:
> >     mainmenu "My own super duper root menu"
> 
> Had forgoten about this - why is it that we do not use this, but invent
> an environment variable?

Just the sake of homogeneity: as I already introduced environment
variable to change the CONFIG_ prefix, then I also added an env var
for the root-menu, too.

But agreed, I'll drop the root-menu patches, since we already havea
run-time solution to override it.

> > > config KCONFIG_SYMBOL_PREFIX
> > > 	string
> > > 	default "SAM_"

OK, I'm tackling this, but my head is on the verge of exploding, trying
to follow all those intricate calls in the kconfig parser/menu layout.

/me goes and gets an aspirin. ;-)

However, rather than hard-coding the symbol name, what about introducing
a new 'option' keyword:
    config BLABLA       # Name of symbol is not meaningful
        string
        default "SAM_"
        option prefix

Currently, the only symbol (AFAIK) that is hard-coded is MODULES, which
can be overloaded with 'option modules' to another symbol. I would not
like to add any hard-coded symbol name.

Michal, as maintainer for this, we need your input:
  - do you want to keep the CONFIG_ environment variable, or do you
    prefer the symbol trick?

If you prefer the env var:
  - are you happy with the current naming?
  - if not, what name do you prefer: KCONFIG_CONFIG_ or KCONFIG_PREFIX,
    or anything else? Then, how do you want me to proceed: send a fix-up
    patch, or re-submit the previous series with the rename?

If you prefer the symbol trick:
  - will just revert my previously applied CONFIG_ series, or should I
    send a fix-up series that removes it before introducing the symbol
    trick?
  - do you prefer we hard-code the feature in the symbol name, or is the
    'option prefix' better suited?

> I never liked (and still do not like) how environment
> variables are used to adjust the front-end behaviour.
> The real reason why we use environment variables is that we cannot
> specify options for kconfig when we invoke make.

Yes, that's also on my todo-list: add a generic option-parsing function
in a common file, and have all frontends call it.

It's on the todo-list. so don't hold your breadth... ;-)

Regards,
Yann E. MORIN.

-- 
.-----------------.--------------------.------------------.--------------------.
|  Yann E. MORIN  | Real-Time Embedded | /"\ ASCII RIBBON | Erics' conspiracy: |
| +33 662 376 056 | Software  Designer | \ / CAMPAIGN     |  ___               |
| +33 223 225 172 `------------.-------:  X  AGAINST      |  \e/  There is no  |
| http://ymorin.is-a-geek.org/ | _/*\_ | / \ HTML MAIL    |   v   conspiracy.  |
'------------------------------^-------^------------------^--------------------'