From: Arnaud Lacombe <lacombar@gmail.com>
To: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
Cc: linux-kernel@vger.kernel.org, linux-kbuild@vger.kernel.org
Subject: Re: [PATCH v2] kconfig: autogenerated config_is_xxx macro
Date: Fri, 6 May 2011 12:19:01 -0400 [thread overview]
Message-ID: <BANLkTi=s8w01NHnxB7cfCvy4ZS5GnUABZg@mail.gmail.com> (raw)
In-Reply-To: <1304658229-30820-1-git-send-email-plagnioj@jcrosoft.com>
Hi,
On Fri, May 6, 2011 at 1:03 AM, Jean-Christophe PLAGNIOL-VILLARD
<plagnioj@jcrosoft.com> wrote:
> this will allow to use to use
>
> if(config_is_xxx())
> if(config_is_xxx_module())
>
> in the code instead of
>
> #ifdef CONFIG_xxx
> #ifdef CONFIG_xxx_MODULE
>
> and now let the compiler remove the non usefull code and not the
> pre-processor
>
Why would it be a good thing ?
Most configuration-dependent code inside functions tends to be moved
to a static inline already, which get conditionally defined based on
the CONFIG_<foo>. If it is not, then the code is badly architectured
(-> bad). Using that if(xxx) notation would also lead to yet more
heavily indented function (-> bad). Moreover, this introduces
yet-another way to check for an information (-> bad), and you will end
up with mixing the config_is_<xxx> notation inside a function
declaration, and CONFIG_<xxx> when not inside a function (-> bad)
Actually, this is even worse than that as you'll not be able to hide
structure (or structure members) inside CONFIG_<xxx> and use that
structure (or structure members) in config_is_<xxx> protected block
without causing compile-time failure.
Thanks,
- Arnaud
> as done in the mach-types for arm as exmaple
>
> Signed-off-by: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@jcrosoft.com>
> ---
> v2:
>
> use config_is
>
> add support of config_is_xxxx_module
>
> Best Regards,
> J.
> scripts/kconfig/confdata.c | 29 +++++++++++++++++++++++++++++
> 1 files changed, 29 insertions(+), 0 deletions(-)
>
> diff --git a/scripts/kconfig/confdata.c b/scripts/kconfig/confdata.c
> index 61c35bf..11b8b31 100644
> --- a/scripts/kconfig/confdata.c
> +++ b/scripts/kconfig/confdata.c
> @@ -778,6 +778,29 @@ out:
> return res;
> }
>
> +static void conf_write_function_autoconf(FILE *out, char* conf, char* name,
> + int val)
> +{
> + char c;
> + char *tmp, *d;
> +
> + d = strdup(conf);
> + tmp = d;
> + while ((c = *conf++))
> + *d++ = tolower(c);
> +
> + fprintf(out, "#define %sis_", tmp);
> + free(tmp);
> +
> + d = strdup(name);
> + tmp = d;
> + while ((c = *name++))
> + *d++ = tolower(c);
> + fprintf(out, "%s%s() %d\n", tmp, (val > 1) ? "_module" : "",
> + val ? 1 : 0);
> + free(tmp);
> +}
> +
> int conf_write_autoconf(void)
> {
> struct symbol *sym;
> @@ -786,6 +809,7 @@ int conf_write_autoconf(void)
> FILE *out, *tristate, *out_h;
> time_t now;
> int i;
> + int fct_val;
>
> sym_clear_all_valid();
>
> @@ -829,6 +853,7 @@ int conf_write_autoconf(void)
> rootmenu.prompt->text, ctime(&now));
>
> for_all_symbols(i, sym) {
> + fct_val = 1;
> sym_calc_value(sym);
> if (!(sym->flags & SYMBOL_WRITE) || !sym->name)
> continue;
> @@ -842,12 +867,14 @@ int conf_write_autoconf(void)
> case S_TRISTATE:
> switch (sym_get_tristate_value(sym)) {
> case no:
> + fct_val = 0;
> break;
> case mod:
> fprintf(tristate, "%s%s=M\n",
> CONFIG_, sym->name);
> fprintf(out_h, "#define %s%s_MODULE 1\n",
> CONFIG_, sym->name);
> + fct_val = 2;
> break;
> case yes:
> if (sym->type == S_TRISTATE)
> @@ -874,8 +901,10 @@ int conf_write_autoconf(void)
> CONFIG_, sym->name, str);
> break;
> default:
> + fct_val = 0;
> break;
> }
> + conf_write_function_autoconf(out_h, CONFIG_, sym->name, fct_val);
> }
> fclose(out);
> fclose(tristate);
> --
> 1.7.4.1
>
> --
> To unsubscribe from this list: send the line "unsubscribe linux-kbuild" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
>
next prev parent reply other threads:[~2011-05-06 16:19 UTC|newest]
Thread overview: 26+ messages / expand[flat|nested] mbox.gz Atom feed top
2011-05-06 5:03 [PATCH v2] kconfig: autogenerated config_is_xxx macro Jean-Christophe PLAGNIOL-VILLARD
2011-05-06 16:19 ` Arnaud Lacombe [this message]
2011-05-07 1:50 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-09 8:52 ` Michal Marek
2011-05-13 8:09 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-13 8:30 ` Ingo Molnar
2011-05-13 8:36 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-13 10:01 ` Ingo Molnar
2011-05-13 10:21 ` Alexey Dobriyan
2011-05-13 10:38 ` Michal Marek
2011-05-13 12:21 ` Ingo Molnar
2011-05-14 10:02 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-13 15:19 ` Arnaud Lacombe
2011-05-16 19:03 ` Valdis.Kletnieks
2011-05-16 19:38 ` Arnaud Lacombe
2011-05-16 20:05 ` Michal Marek
2011-05-16 20:24 ` Arnaud Lacombe
2011-05-16 20:33 ` Michal Marek
2011-05-17 1:08 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-17 1:03 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-17 19:13 ` Valdis.Kletnieks
2011-05-18 5:27 ` Jean-Christophe PLAGNIOL-VILLARD
2011-05-13 16:26 ` Andi Kleen
2011-05-13 18:18 ` Arnaud Lacombe
2011-05-17 14:45 ` Michal Marek
2011-05-17 18:19 ` Jean-Christophe PLAGNIOL-VILLARD
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='BANLkTi=s8w01NHnxB7cfCvy4ZS5GnUABZg@mail.gmail.com' \
--to=lacombar@gmail.com \
--cc=linux-kbuild@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=plagnioj@jcrosoft.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).