On Sat, 24 Aug 2002, Greg Banks wrote:
| Peter Samuelson wrote:
|
| [Randy.Dunlap]
| Is there a script that checks for CONFIG_ variable dependency ordering
| in [Cc]onfig.in files? If so, where can I get it?
|
|http://www.alphalink.com.au/~gnb/gcml2/
|
| Thanks, Peter. Randy, the
Randy.Dunlap wrote:
On Sat, 24 Aug 2002, Greg Banks wrote:
| Peter Samuelson wrote:
|
|http://www.alphalink.com.au/~gnb/gcml2/
Thanks. I'm trying it out now.
BTW Greg, your checker web page spells 'dependency' as
'dependancy' in a few places.
Damn. It's a good thing I didn't
Hi,
On Thu, 22 Aug 2002, Greg Banks wrote:
Why do you want to do the parser/syntax switch separately? Why do you want
to write and test a parser just to be throw it away again?
So that the changes have some chance of getting past Linus.
Sorry, but that's a dumb reason. Linus is quite
Roman Zippel wrote:
Hi,
On Thu, 22 Aug 2002, Greg Banks wrote:
Why do you want to do the parser/syntax switch separately? Why do you want
to write and test a parser just to be throw it away again?
So that the changes have some chance of getting past Linus.
Sorry, but that's a
[EMAIL PROTECTED] (Greg Banks) wrote on 19.08.02 in
[EMAIL PROTECTED]:
In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2
David Woodhouse gives an idea of what would be necessary to get a new
language+parser accepted. Can you achieve that yet?
As for the idea of a new
On Mon, Aug 19, 2002 at 11:48:00PM +0200, Kai Henningsen wrote:
[EMAIL PROTECTED] (Greg Banks) wrote on 19.08.02 in
[EMAIL PROTECTED]:
In http://marc.theaimsgroup.com/?l=linux-kernelm=101387128818052w=2
David Woodhouse gives an idea of what would be necessary to get a new
[EMAIL PROTECTED] said:
David suggest to use randomly generated configurations, but they lack
one important feature. They are always valid, and a new system shall
be able to deal with hand-edited .config files in the same way as
oldconfig.
I suggested those as a way for testing the
Hi,
On Wed, 21 Aug 2002, Greg Banks wrote:
I have to manually fix things like CONFIG_ALPHA_NONAME, which is first set
by a choice statement and later redefined. My new parser can't deal with
this, because user input is given the highest priority.
Well then, there's something we need to
Roman Zippel wrote:
The problem here is one should consider, how all these little changes will
help to solve the big problems. Do they allow to more easily fix the big
problems or have these changes to be dumped again?
I believe fixing the existing rules within the existing syntax is an
Hi,
On Mon, 19 Aug 2002, Greg Banks wrote:
Unlike you, I'm not optimistic that a switch to a new language or even a new
parser for the old language will ever happen.
It would be nice if I could get it into 2.6, but it's not a problem if it
has to wait. I'm currently busy getting menuconfig
On Mon, Aug 19, 2002 at 07:27:50PM +1000, Greg Banks wrote:
I'm not optimistic that a switch to a new language or even a new
parser for the old language will ever happen.
I asked Linus specifically about the replacement of the shell based parsers.
The answer were quite simple:
- It should be
Hi,
(Could you please fix your mailer? linux-m68k.org.com does not really
exist.)
On Thu, 15 Aug 2002, Greg Banks wrote:
The problems are really not simple, the current config language is very
limited, [...]
I don't think anyone who actually understands the config system would
argue
On Thu, 15 Aug 2002, Roman Zippel wrote:
I don't think anyone who actually understands the config system would
argue these points, but we are limited by practical constraints to making
incremental improvements only.
That's fine with me, but nonetheless I'd really like to know where it
Roman Zippel wrote:
Hi,
(Could you please fix your mailer? linux-m68k.org.com does not really
exist.)
I believe the problem is upstream of the machine I control. I'll see what I can do.
That's fine with me, but nonetheless I'd really like to know where it will
go to. Just fixing the
[John Alvord]
I've been puzzling about this problem and the CML2 trainwreck.
Maybe we can used advanced tools to remove the many bugs and
inconsistancies and then switch to a better config tool.
That's exactly what we're trying to do. Greg has the advanced
consistency checking, and I've
Hi,
On Tue, 13 Aug 2002, Peter Samuelson wrote:
Mutating the language, long-term, so that it looks less like sh and
more like a specialised language, is IMO a worthy goal. And I think
it can be done. The main thing to deal with is adding an alternative
syntax for 'if' statements which
Peter Samuelson wrote:
[Greg Banks]
[...CONFIG_SERIAL and CONFIG_PCMCIA warnings...]
Hmmm, either I missed those in your earlier messages, or you didn't
post them.
Probably I didn't post them. What I posted was a small subset of the full log.
+ dep_tristate ' I2C bit-banging
Roman Zippel wrote:
Hi,
On Tue, 13 Aug 2002, Peter Samuelson wrote:
Mutating the language, long-term, so that it looks less like sh [...]
That doesn't solve any of the more fundamental problems.
Correct, it doesn't.
1) We still have 3 config parsers, which produce slightly
[Greg Banks]
+ dep_tristate ' I2C bit-banging interfaces' CONFIG_I2C_ALGOBIT $CONFIG_I2C
Are you sure want this one there?
I didn't like it either, but it's needed in a couple odd places. What
would you suggest - moving the whole i2c menu up?
Not all the way up to the new
Peter Samuelson wrote:
[Greg Banks]
+2 CONFIG_KMOD
+2 CONFIG_MODULES
+2 CONFIG_MODVERSIONS
2 CONFIG_RTC
What does that mean? All I did there was to combine two toplevel
menus into one. Did this do something bad?
Apparently.
On Thu, 15 Aug 2002 11:52:48 +1000, Greg Banks [EMAIL PROTECTED]
wrote:
Roman Zippel wrote:
Hi,
On Tue, 13 Aug 2002, Peter Samuelson wrote:
Mutating the language, long-term, so that it looks less like sh [...]
That doesn't solve any of the more fundamental problems.
Correct, it
Hi,
On Mon, 12 Aug 2002, Peter Samuelson wrote:
tristate DRV
dep_mbool DRV_OLD DRV
dep_mbool COMMON_OPT DRV
dep_mbool OLD_OPT1 DRV_OLD
dep_mbool OLD_OPT2 DRV_OLD
dep_mbool NEW_OPT1 DRV !DRV_OLD
dep_mbool NEW_OPT2 DRV !DRV_OLD
This way you can't compile old and new driver as module.
Hi,
On Tue, 13 Aug 2002, Greg Banks wrote:
This doesn't has be
very painful, I have a tool that can convert most of the current config
into whatever you want.
The problem is deciding what the original rules were supposed to mean, and
then reproducing that behaviour exactly in the new
Roman Zippel wrote:
On Tue, 13 Aug 2002, Greg Banks wrote:
The problem is deciding what the original rules were supposed to mean, and
then reproducing that behaviour exactly in the new language. The alternative
is fixing the problems as we convert, but then we end up with CML2 and the
Peter Samuelson wrote:
[...] what would be
*really* nice would be a way to determine that a particular forward
declared symbol is actually a never-in-this-arch declared symbol.
Ok, here it is.
Greg.
--
the price of civilisation today is a courageous willingness to prevail,
with force,
On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote:
977missing-experimental-tag
113spurious-experimental-tag
145variant-experimental-tag
30 inconsistent-experimental-tag
13 missing-obsolete-tag
41 spurious-obsolete-tag
25 variant-obsolete-tag
How about
[Greg Banks]
Ok, here it is.
Thanks again. It will take some time to double-check what I termed
the false positives, but now you've reduced the interesting cases
down to 30 symbols.
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines
[Sam Ravnborg]
How about extending the language (side effect) to automagically
append (EXPERIMENTAL) or (OBSOLETE) to the menu line, if dependent
on those special tags?
I've thought about that too. Menuconfig already has magic code to
append ' (NEW)' if it hasn't seen a symbol before.
Your
On Tue, 13 Aug 2002, Peter Samuelson wrote:
CONFIG_PROC_FS is needed by ISDN hysdn. That's actually in my opinion
more of a general kernel facility than a filesystem. Eh?
Well, the use in hysdn can (and should) die, possibly by adding an
#ifndef CONFIG_PROC_FS
#error This driver won't work
[Kai Germaschewski]
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.
Yes. That's my current plan.
Basically, extend the source command to do a grep CONFIG_* in the
file to be read
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
Sam Ravnborg wrote:
On Tue, Aug 13, 2002 at 01:23:19PM +1000, Greg Banks wrote:
977missing-experimental-tag
113spurious-experimental-tag
145variant-experimental-tag
30 inconsistent-experimental-tag
13 missing-obsolete-tag
41 spurious-obsolete-tag
25
Kai Germaschewski wrote:
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
[I wrote]
sed '/dep_/s/ \$CONFIG_/ CONFIG_/g' is quite effective. In any
case it is not hard to support both syntaxes - once the transition
is complete,
[Greg Banks]
Does complete mean all the ports have also made the change and
been merged back?
Either that, or, Linus gets tired of
[Greg Banks]
define_bool CONFIG_QUUX y
bool 'Set this symbol to ON' CONFIG_FOO
if [ $CONFIG_FOO = y ]; then
bool 'Here QUUX is a query symbol' CONFIG_QUUX
fi
It's (somewhat) well-known that things tend to fly apart when you try
to redefine a symbol. I don't see
[Greg Banks]
[I wrote]
(BTW, the format is great - I can use 'M-x compile' and 'M-x
next-error' and Emacs pulls up files and lines for me.)
This is not a coincidence.
Indeed not - if you hadn't already used that format I would have
munged it. Grew up on gcc, so this is my favorite
Kai Germaschewski wrote:
On Wed, 14 Aug 2002, Greg Banks wrote:
Peter Samuelson wrote:
[Greg Banks]
Does complete mean all the ports have also made the change and
been merged back?
[...]
Actually I suspect it would be more like the C99 thing: after the new
syntax is
Peter Samuelson wrote:
You're willing to potentially perturb 2.4?
This stuff is trivial enough, and easy enough to test, that I think it
could go in 2.4, yes.
I think you're underestimating the Gordian knot that is the CML1 corpus.
Obviously xconfig would need to be dealt with
in
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.
[I wrote]
This stuff is trivial enough, and easy enough to test, that I
think it could go in 2.4, yes.
[Greg Banks]
I think you're underestimating the Gordian knot that is the CML1 corpus.
Yes, very possibly.
To pick an example, in 2.5.29 drivers/ide/Config.in:17 is
dep_tristate
On Mon, Aug 12, 2002 at 09:45:37PM +0200, Roman Zippel wrote:
More examples of the cml1 limitations can be found in arch/ppc/config.in -
a single choice statement needs to be splitted into multiple choice
statements.
Er, which are you referring to here? All of the choice statements are
done
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
More examples of the cml1 limitations can be found in arch/ppc/config.in -
a single choice statement needs to be splitted into multiple choice
statements.
Er, which are you referring to here? All of the choice statements are
done for clarity
On Tue, Aug 13, 2002 at 12:13:51AM +0200, Roman Zippel wrote:
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
More examples of the cml1 limitations can be found in arch/ppc/config.in -
a single choice statement needs to be splitted into multiple choice
statements.
Er, which are you
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
There is still a bit of overlap. Roughly it's possible to sort the machine
types by cpu type, but IMO it's not the best solution. I think it would be
better to sort them by general machine type.
Er, 'general machine type' ?
+-RPX
| +- ...
+-TQM
On Tue, Aug 13, 2002 at 12:32:50AM +0200, Roman Zippel wrote:
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
There is still a bit of overlap. Roughly it's possible to sort the machine
types by cpu type, but IMO it's not the best solution. I think it would be
better to sort them by
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
A bit more flexibility certainly wouldn't hurt. :)
What does that gain however? And it wouldn't make as much sense to
offer the IBM Spruce (750) next to the IBM Walnut (405GP).
You weren't forced to sort them by cpu type. Maybe it works as is, you
On Tue, Aug 13, 2002 at 01:17:15AM +0200, Roman Zippel wrote:
Hi,
On Mon, 12 Aug 2002, Tom Rini wrote:
A bit more flexibility certainly wouldn't hurt. :)
What does that gain however? And it wouldn't make as much sense to
offer the IBM Spruce (750) next to the IBM Walnut (405GP).
[Roman Zippel]
with the latest modifications this can be written as:
dep_tristate NEW !OLD
dep_tristate OLD !NEW
This still has the back reference and you have to run 'make config'
twice to change NEW from n to y.
I don't see this as a big problem. Most people don't use the bare
Peter Samuelson wrote:
[...]CONFIG_BLK_DEV_IDESCSI[...]
That one example is more than enough to convince me *not* to try
changing the ignore empty deps rule for 2.4. 2.5 is a different
matter, though..
Ah, good.
This is like the Stanford checker stuff. These are bugs. You have
Roman Zippel wrote:
Most should be fixable. The biggest problem are recursive references like
this:
if [ OLD != y ]; then
tristate NEW
fi
if [ NEW != y ]; then
tristate OLD
fi
[...]It's possible to fix this:
tristate DRV
if [ DRV == y ]; then
choice OLD NEW
fi
if [ DRV
Roman Zippel wrote:
I only used it as an example, because my tool has problems to
automatically convert this construct into something useful (e.g. because
of CONFIG_WILLOW in 2 seperate choice statements).
You too? I had to rewrite my branch merging code to make CONFIG_WILLOW fit.
Greg.
[Greg Banks]
Ah. If you're willing to knowingly feed Linus with patches that
break current config behaviour, then OK we have a way to proceed.
Things knowingly break in 2.5 all the time. I for one have no problem
with this. Especially since the breakage is so easy to pinpoint,
thanks to
Peter Samuelson wrote:
[Greg Banks]
Ah, glad you asked, see attached output from the latest version of gcml2
(not yet released).
Thank you thank you thank you! Exactly what I wanted!
Pleased to be of service ;-)
Now, while some (perhaps a lot) of these instances will break with the
[Greg Banks]
I like the basic idea here, and I'm pleased that someone has the
courage to tackle some of the brokenness of the kconfig language (if
only because it will provide me with a precedent when I try to
submit some of my patches ;-).
Thanks for the feedback. (:
This applies to
54 matches
Mail list logo
