Linus, replying to Alan:
>> If we do that I'd rather see a make autoconfig that does the lot from
>> proc/pci etc 8)
>
>Good point. No point in adding a new config option, we should just have a
>new configurator instead. Of course, it can't handle many of the
>questions, so it would still have to fall back on asking.
Andre forwarded this to me, asking:
>Would this sort of auto-configuration be difficult to implent in [CML2]?
Summary answer:
CML2 doesn't handle this now -- and I'd prefer for it not to, as I
think a separate batch-mode autoconfigurator feeding its results to
CML2 as a partial config would be better design. But it could be done
without much difficulty.
Detailed answer:
My original design for CML2 included a way to capture the results from
arbitrary procedural probes written in C or some scripting language
and use them in predicates. Imagine something like this:
# PROCESSOR is string valued; we capture stdout from the probe
derive PROCESSOR from "myprobe1.sh"
# FOOFEATURE is boolean; we look at the return status from myprobe2.py
derive FOOFEATURE from "myprobe2.py"
Alan, with simple probes that investigate proc/pci this would do exactly
what you want. Such a feature would be easy to implement in CML2. With
a little work, I could even support inline probe procedures declared
in the rules file itself.
I backed away from this because Giacomo Catenazzi told me he was
working on a separate autoconfigurator that would generate config
files in CML1 format. That's a cleaner design -- one would run his
autoconfigurator and then import the resulting config into the CML2
configurator as frozen (immutable) symbols. Giacomo, what's the state
of your project?
(kbuild people, this is one reason I want ifdefs gone from the
makefiles. The autoconfigurator, whether it's Giacomo's or not,
should be able to pass FOO=n to tell CML2 that a given feature is
definitely not present.)
For later:
If Giacomo's attempt at an autoconfigurator fails, I will tackle
this problem -- but only with CML2 adopted and in place first.
Otherwise handling all the grotty CML1 details would be just
too nasty.
-- >>esr>> - To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.kernel.org Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Sun Dec 31 2000 - 21:00:09 EST