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 different
> .config files.
Yes.
> 2) To integrate a new driver, you have to touch at least 3 files:
> Config.in, Config.help, Makefile. Properly configuring and building a
> driver outside of the tree is painful to impossible.
Yes.
> 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 these points, but we are limited by practical constraints to making
incremental improvements only.
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.
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 doesn't.
>
>> 1) We still have 3 config parsers, which produce slightly different
>> .config files.
>
>Yes.
>
>> 2) To integrate a new driver, you have to touch at least 3 files:
>> Config.in, Config.help, Makefile. Properly configuring and building a
>> driver outside of the tree is painful to impossible.
>
>Yes.
>
>> 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 these points, but we are limited by practical constraints to making
>incremental improvements only.
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 way the
rulebase will be (almost) identical when the config process changes.
john alvord
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 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 will
go to. Just fixing the easy problems is simple, but so far I haven't seen
any plan on how to fix the hard problems. Anyone starting to fix all the
problems should have at least some ideas how to do it and I'd really like
to hear them. I don't want to discourage anyone, but he should understand
the complete problem first before going for the easy targets.
bye, Roman
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 will
> go to. Just fixing the easy problems is simple, but so far I haven't seen
> any plan on how to fix the hard problems. Anyone starting to fix all the
> problems should have at least some ideas how to do it and I'd really like
> to hear them. I don't want to discourage anyone, but he should understand
> the complete problem first before going for the easy targets.
I think concentrating on the small gotchas for now is a good thing.
Surely not all conceptual problems are fixable easily, they probably need
to be done in conjunction with switching to a common parser etc. (Note:
this switch to a new parser should happen with no change to the config.in
format or semantics, in order to fit the Linux/Linus way of doing things).
However, I think it is too late in 2.5 for these kind of big changes.
That doesn't mean that fixing bugs, of which there are plenty, and small
improvements like "" == "n" where possible shouldn't be done. If nothing
else, it will at least give a better starting point for more elaborate
work later.
--Kai
Hi,
On Thu, 15 Aug 2002, Kai Germaschewski wrote:
> Surely not all conceptual problems are fixable easily, they probably need
> to be done in conjunction with switching to a common parser etc. (Note:
> this switch to a new parser should happen with no change to the config.in
> format or semantics, in order to fit the Linux/Linus way of doing things).
This is where I disagree. Switching the parser and the syntax separately
would mean two big changes, that need to be tested. You actually have to
write two parsers, one that emulates the shell behaviour as exactly as
possible and a second parser that get rids of that again. Doing a single
switch would be far less painful.
There are some corner cases in the current rulebase, which are difficult/
ambiguous for a compiling parser (instead of interpreting). These cases
are mostly in arch/*/config.in files, which were probably never tested
with xconfig.
My converter can convert almost everything, with some small changes to the
input files it should also be able to convert the rest. The resulting
needs some small editing to be completely useable, so this process is not
completely automatic (The reason for this are the recursive dependencies,
which need some small manual fixing).
I tried very hard to make that switch as painless as possible. By
automatically converting the config the rulebase is still almost the same.
Normal users will hardly see a difference (except for xconfig, as that
is reimplemented in QT).
> However, I think it is too late in 2.5 for these kind of big changes.
Most of the work is actually already done, there isn't that much left to
be completely usable. If anyone wants to help, I'd be happy.
bye, Roman
[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 been trying to remove ambiguities and
warts in the current rule corpus, and simultaneously come up with some
extensions to the current language that will let us remove *more*
warts. The extensions are designed to completely supplant certain
existing constructs which I consider ugly and difficult to parse.
To paraphrase Orwell: it was intended that when Newspeak had been
adopted once and for all and Oldspeak forgotten, a buggy parser should
be literally unimplementable, at least so far as implementation is
dependent on clear syntax and reasonable semantics.
Peter