I have been looking at Giacomo's autoconfigure.sh code and thinking
about it should communicate with CML2. I like the concept, and the
implementation starting from a table of probe routines calls in a
rules file is clever.
Unfortunately, as the program is now it yields mostly information about
what is present on the system, not information about hardware and features
that are known *not* to be present.
To reduce the complexity of the user's configuration task to a
minimum, autoconfigure.sh should not merely be able to list (for
example) all the PCI hardware on the system, it should also be able to
assert that the symbols for all *other* PCI hardware should be frozen
to `n' so so none of those questions will ever be asked.
Similar considerations obtain for any bus with a registry (such as
I2O), but PCI is the most important case so I'll keep using it as an
example.
The design question then becomes this: who knows what the set of all
PCI devices is, and computes the complement of the set of detected devices?
There are several possible answers to this question. Each has different
design implications.
autoconfigure.sh itself could compute the set complement. This implies
that either (a) autoconfigure.sh itself would have to contain a list of all
symbols dependent on PCI or (b) such a list would have to live in the
autoconfigure.rules file.
Both these design choices would be poor. The major problem is that either
would duplicate knowledge already present in the configuration rulebase,
probably leading to inconsistencies and certainly creating an unpleasant
maintainance task.
This leads us directly to the second possibility, that
autoconfigure.sh could read the configuration rulebase and use that
information to compute the complement set. This could work in one of
two ways: either (a) autoconfigure.sh could process the pickled CML2
rulebase itself (in which case it would have to be rewritten at least
partly in Python) or (b) autoconfigure.sh could call an agent program
to generate the list for it (adding an option to kxref.py to do this
would be nearly trivial).
There is a third possibility. autoconfigure.sh is going to pass its
results to cmlconfigure.py in a file with the format of a config.out.
Right now all those results are symbol bindings (FOO=y, BAR=n).
Conceivably autoconfigure.sh could also pass a directive like
"finished PCI" which would tell cmlconfigure.py that all PCI-dependent
symbols not yet set should be set to `n'.
Either of these alternatives (autoconfigure.sh querying the rulebase
or passing a directive to cmlconfigure.py) could work nicely. Which
is the right thing is really a question of design philosophy -- that
is, what do we *want* the roles of autoconfigure.sh and
cmlconfigure.py to be? And how closely coupled should they be?
I don't have strong opinions on either question. But I want to get them
on the table so we'll think about them at a design level before rushing
to code.
--
<a href="http://www.tuxedo.org/~esr/";>Eric S. Raymond</a>
Rifles, muskets, long-bows and hand-grenades are inherently democratic
weapons. A complex weapon makes the strong stronger, while a simple
weapon -- so long as there is no answer to it -- gives claws to the
weak.
-- George Orwell, "You and the Atom Bomb", 1945
_______________________________________________
kbuild-devel mailing list
[EMAIL PROTECTED]
https://lists.sourceforge.net/lists/listinfo/kbuild-devel
