[Sorry, resent to lkml with attachment gzip'ed]
Kai Germaschewski wrote:
>
> On Mon, 12 Aug 2002, Greg Banks wrote:
>
> > 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,
Sorry, I don't understand what you're getting at. Currently the behaviour is
consistent between config, menuconfig and xconfig: null-valued deps are ignored.
> CONFIG_BLK_DEV_IDESCSI would
> be not selectable in either. So people would have to notice that this
> statement is broken and fix it.
Ah. If you're willing to knowingly feed Linus with patches that break current
config behaviour, then OK we have a way to proceed.
> > 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.
Sorry, didn't see that.
> So you agree a bit of spring cleaning wouldn't hurt, right? ;)
Absolutely, and I have a catalogue of dust puppies to help that process ;-)
> > > It seems to me that it only encourages buggy
> > > Config.in 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.
CML2's semantics were that all symbols have a default which is a zero; for
booleans and tristates that means "n". Changing from those semantics to the
ones necessary to run the gcml2 rulebase on CML1 rules was one of the most
painful parts of supporting CML1.
So I think having an explicit "n" default is a good idea, but I fail to see how
you would actually implement such a thing in a shell based parser.
> 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 is precisely the CML2 semantics.
> Of course, this is a 2.5 change,
Agreed.
> though the only potential for breakage
> are the dep_* statements which are arguably already broken.
I don't think there's any value to gratuitously breaking 2.4's config.
That's the point of a "stable" series right?
> 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.
Ah, glad you asked, see attached output from the latest version of gcml2
(not yet released).
Greg.
-- the price of civilisation today is a courageous willingness to prevail, with force, if necessary, against whatever vicious and uncomprehending enemies try to strike it down. - Roger Sandall, The Age, 28Sep2001.
- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Thu Aug 15 2002 - 22:00:31 EST