Re: [patch] config language dep_* enhancements

From: Kai Germaschewski (kai-germaschewski@uiowa.edu)
Date: Tue Aug 13 2002 - 13:43:13 EST


On Tue, 13 Aug 2002, Greg Banks wrote:

> Kai Germaschewski wrote:
> >
> > 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.

For some reason, I thought that menuconfig or xconfig were handling the ""
case differently. Apparently not, sorry about that.

> > 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.

Well, it'd be nice to first "fix" the dep_* statements so that they don't
break when that change is done (i.e. in this case, moving IDESCSI behind
CONFIG_SCSI.

> > 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 ;-)

Okay. Let me first state that I do not really have the time to get
involved currently. ISDN4Linux and other pending kbuild stuff already
takes somewhat more than the remaining free time I have. But if you guys
want to get going with some step by step cleaning (w/o breaking too much),
I can try to help reviewing and submitting to Linus.

> > 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.

Basically, extend the "source" command to do a grep CONFIG_* in the file
to be read and set all found symbols to "n", if unset - only then do
the actual "source".

> > 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?

I agree.

Anyway, some more points:

o a) dep_bool ' Blah' CONFIG_FOO $CONFIG_BAR vs.
  b) dep_bool ' Blah' CONFIG_FOO CONFIG_BAR

  (the latter proposed by Peter Samuelson)

  I see the following:
  b) needs a large scale patch through all Config.in's. OTOH, it can be
  done step by step, only changing an instance after it has been looked
  at. a) means only a patch to Configure/menuconfig etc, but since it
  changes semantics, it'd be nice to check all possibly breaking usages
  (not too hard thanks to gcml2)

  I find a) more intuitive, for people who know sh, it's pretty clear
  when we use "$" and when not. Also, for 'if' statements, we'll have to
  use the "$" variant anyway for all I can see, so I prefer that from a
  consistency point of view.

  b) is better if you want to add features like automatic
  "(EXPERIMENTAL)"

  a) has the advantage of automatically getting rid of the ugly duplicated
  'if' tests: (And I think it should allow for getting rid of the
  quotation marks, too)

  if [ "$CONFIG_FOO" = "" -o "$CONFIG_FOO" = "n" ]
     --> if [ "$CONFIG_FOO" == "n" ]
  if [ "$CONFIG_FOO" = "y" -o "$CONFIG_FOO" = "m" ]
     --> if [ "$CONFIG_FOO" != "n" ]

o whatever we do, having a nice way to handle two exclusive drivers would
  be nice

--Kai

-
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:33 EST