[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20110507015041.GA21017@game.jcrosoft.org>
Date: Sat, 7 May 2011 03:50:41 +0200
From: Jean-Christophe PLAGNIOL-VILLARD <plagnioj@...osoft.com>
To: Arnaud Lacombe <lacombar@...il.com>
Cc: linux-kernel@...r.kernel.org, linux-kbuild@...r.kernel.org
Subject: Re: [PATCH v2] kconfig: autogenerated config_is_xxx macro
On 12:19 Fri 06 May , Arnaud Lacombe wrote:
> Hi,
>
> On Fri, May 6, 2011 at 1:03 AM, Jean-Christophe PLAGNIOL-VILLARD
> <plagnioj@...osoft.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.
sorry but conditionnal structure members is bad practice
you save nearly no space nut for the test of the code in multiple
configuration. Use union for this.
the compile-time failure is good here. it's means your code is not generic.
specially when you want to keep code running on multiple soc/arch keep compiling
no matter the configuration
#ifdef in the code is a really bad habit
Best Regards,
J.
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists