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
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
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,
[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 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
[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
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
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
30 matches
Mail list logo
