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 [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/