[<prev] [next>] [<thread-prev] [day] [month] [year] [list]
Message-ID: <Pine.LNX.4.64.0703211244150.14457@scrub.home>
Date: Wed, 21 Mar 2007 12:59:37 +0100 (CET)
From: Roman Zippel <zippel@...ux-m68k.org>
To: Geert Uytterhoeven <Geert.Uytterhoeven@...ycom.com>
cc: Linus Torvalds <torvalds@...ux-foundation.org>,
Al Viro <viro@....linux.org.uk>,
Linux Kernel Development <linux-kernel@...r.kernel.org>
Subject: Re: kconfig `bool' (was: Re: [PATCH 13/13] fix ps3fb glue allowing
a modular build)
Hi,
On Tue, 20 Mar 2007, Geert Uytterhoeven wrote:
> On Wed, 14 Mar 2007, Linus Torvalds wrote:
> > In many ways it would be nice if we had two different kinds of "bool": one
> > where "m" in the dependency chain means "y" is ok, and one where "m" means
> > "n".
> >
> > We used to have "dep_bool" and "dep_mbool" for this, a long time ago. It
> > got dropped in the Kconfig language rewrite, and I think it was a mistake.
Well, it wasn't really dropped, just the syntax changed...
There were only one or two rules which depended on the dep_bool syntax and
it were special cases anyway.
> > So I think it would be nice to re-introduce it. As it is, we have a number
> > of Kconfig language constructs that are just unnecessarily hard to
> > understand, because we end up having to add a "= y" or similar.
> >
> > The rule *used* to be: "dep_mbool" was a boolean that was valid even for
> > modules, while "dep_bool" was a boolean that was valid only for straigth
> > "y", and a module would turn it off.
> >
> > Maybe not "bool" vs "mbool", but it might be nice to have
> >
> > bool FB_PS3
> > depends strictly on FB
> >
> > ie a "depends strictly" refuses to upgrade a bool dependency from "m" to
> > "y", while a regular depends allows it.
> >
> > Or something.. The "depends strictly on X" thing would really be just a
> > mental shorthand for "depends on (X)=y" (it's actually longer to type, but
> > I think it's a bit more intuitive, thus "mental shortcut").
I'm not sure this would really an improvement, for the casual reader X=y
is IMO more readable if he knows the basic kconfig syntax, whereas he had
to lookup first what "strictly" means. Also the potential user had to know
about this syntax, but it's simply not needed often enough that it would
be common and might be easily forgotten if one fixed the driver and
changed the bool to tristate.
> I've been thinking about this a bit more...
>
> Kconfig knows about the following types:
> o bool
> o tristate
> o string
> o hex
> o int
>
> However, from a semantical point of view, they can be subdivided in 2 classes:
> 1. driver/subsystem/library enablers (i.e. things that are used in a Makefile
> to decide whether to compile a unit or not):
> o tristate (y=builtin, m=loadable, n=disabled)
> o bool (y=builtin, n=disabled)
> 2. options (i.e. things that control some features, limits, or default
> values):
> o bool (y=true, n=false)
> o string (literal)
> o hex (literal)
> o int (literal)
>
> The confusion arises from the 2 different semantics for `bool': for the former,
> a `depends on' obviously cannot be `builtin' if the dependency is `modular',
> while for the latter, it can be `true' if the dependency is `modular'.
What I'm considering in this context is to introduce a syntax to
specifically describe modules (e.g. to also generate the Makefile from
it):
module FB_PS3
bool ".."
depends on FB
In this context it would be valid to add the requirement that the
dependencies must be 'y'.
bye, Roman
-
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