[lkml]   [2002]   [Aug]   [12]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
SubjectRe: [patch] config language dep_* enhancements
On Mon, 12 Aug 2002, Greg Banks wrote:

> > > I'm pleased to see that you have preserved those semantics. There
> > > are many places in the corpus where a dep_* lists as a dependency a
> > > variable which is not defined until later, or is only defined in
> > > some architectures, or is never defined. Earlier today I tweaked up
> > > gcml2 to detect them and found 260 in 2.5.29.
> >
> > You give me too much credit. The main motivation for dropping the '$'
> > was to make possible the "" == "n" semantics. That the patch failed
> > to do so was accident, not design.
> Ah, well that's more disturbing. Changing the existing semantics, regardless
> of how broken we all agree they are, is asking for a world of trouble. To
> pick an example, in 2.5.29 drivers/ide/ is
> But at this point in the menu tree for 14 of 17 architectures, CONFIG_SCSI has
> not yet been defined. The result is that CONFIG_BLK_DEV_IDESCSI only works
> in "make config" and "make allyesconfig" precisely because of the semantic that
> you wish to change.

But so the change would be a good thing, right? It would make the behavior
consistent between all configuration tools, CONFIG_BLK_DEV_IDESCSI would
be not selectable in either. So people would have to notice that this
statement is broken and fix it.

> > I know the current behavior is documented, but I had thought this was
> > because changing the behavior was not feasible due to our Bash-based
> > "JIT parsers".
> Yes, changing the behaviour is infeasible with shell-based parsers. However,
> there is now a body of rules which implictly depend on the semantics.

If they do, they should be fixed. And, as I pointed out before, it is
possible to fix even shell-based parsers.

> > Can you provide a rationale for why the current
> > behavior is desirable?
> I wouldn't call it "desirable". I would use words like "clunky", "congealed",
> "unorthogonal", "riddled with errors", and "very hard to fix" like the rest of
> the config language.

So you agree a bit of spring cleaning wouldn't hurt, right? ;)

> > It seems to me that it only encourages buggy
> > code (since "" == "n" in other contexts like the #defines),
> And "" != "n" in other contexts, like if [];then statements. Did I mention
> "unorthogonal" ?

Well, you're right here. Which makes me think of my original idea as to
define all CONFIG_* values to "n" unless they've explicitly been assign
another value before.

> The problem is that logic in config language is implicitly four-state, with
> the null or empty value being a separate value distinct from y, m and n.
> The fact that both "" and "n" mean "don't build this object" to kbuild doesn't
> mean that "" and "n" are the same thing. This isn't really obvious.
> One example where there is a semantic difference between "" and "n" would be
> an autoconfigurator, where "n" would mean "I have probed for this hardware and
> it is not present" but "" means something like "I have not probed".

The main usage currently is "make oldconfig", though .config may be a bit
confusing: Questions which have been answered before (even with "n") will
not be asked again, whereas for undefined symbols, the corresponding
question is put.

So I think the logic should really be tristate, "n","m","y", plus
additionally a list of CONFIG_* values which have been defined (as opposed
to just being "n" by default). This would get rid of the non-intuitive
behavior of dep_* and allow simplifying all the if [ == "n" || == "" ]
duplication. It's a bit cumbersome to implement in shell, but surely

Of course, this is a 2.5 change, though the only potential for breakage
are the dep_* statements which are arguably already broken. It shouldn't
be too hard to come up with a script which points out the dep_* statements
which reference symbols defined only later (or use gcml2, which I
understand can do that already?) to see how much breakage there may be.


To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to
More majordomo info at
Please read the FAQ at

 \ /
  Last update: 2005-03-22 13:22    [W:0.228 / U:2.448 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site