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>>
[CC: list drastically trimmed]
[email protected] (Eric S. Raymond) wrote on 26.12.00 in <[email protected]>:
> 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.
> 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"
I hope that design wouldn't mean that you can't configure a kernel on a
machine different from the one supposed to run it, nor that you can't
gather the autoconfiguration info on a machine where you won't build the
kernel and don't have the full kernel sources.
Because that's a rather common situation in nontrivial installations.
MfG Kai
"Eric S. Raymond" wrote:
>
> 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?
Status:
Now I can detect most of modern hardware, and also some software
protocols.
My autoconfiguration only in few case say N, because is it difficult
to say: you don't need this drivers (e.g. the Matrox Millemium
include a list of PCI devices, but my card is not included,
but anyway, the driver works, because after the check of PCI ID, it
do further checks on other video PCI class).
I'm happy with the autodetection. I need some other software protocols
to detect, but it is difficult to distinguish: "need protocols" and
"protocols included in actual kernel (but nobody will use it)".
I've difficult to merge with the CML1/2:
In CML2-0.8.3 the include frozen flag (-I) is broken, and
also the new -W flag is broken, thus no real test.
CML2-0.9.0 need Python 2, which is not in the debian unstable
distribution, and I had no time to compile myself.
CML1: There is to many not answered question (most not important)
thus it has little value in use with make oldconfig.
(CML2 has a "oldmenuconfig and oldxconfig")
Thus I should modify the Configure files, but with CML2....
I will also add a NOVICE/NORMAL/EXPERT configuration menu,
to include ELF, COFF, IPC, SHM, ... . It is in project since
lots of days, but ELM, COFF, ELF64 are processor dependent,
and I don't find (yet) a clean method to include this
dependence (CML2).
giacomo
TODO: a correct/complete autodetection of CPU.
I forgot:
The program is in http://people.debian.org/~cate/autoconfigure/
Notes of implementation:
It is a bash script. I've split in two file:
rules file: contain the pci id, device name, resources names,...
It is in a simple format, so that it can used in other programs.
Every resource has also a comment writing where I found it in
kernel sources.
main file: define how to use the rules file and how to detect
special configurations.
The autoconfiguration can be done in an external (target) machine
(it doesn't need nothing of kernel, no lspci, no special programs).
Now autoconfigure is in debug mode:
It write some extra debug information and rewrite twice some config
(one for every time it is detected). It write now only to std output,
to not corrupt actual .config files.
giacomo
Giacomo A. Catenazzi <[email protected]>:
> I've difficult to merge with the CML1/2:
>
> In CML2-0.8.3 the include frozen flag (-I) is broken, and
> also the new -W flag is broken, thus no real test.
0.9.0 fixes the -W flag. I wasn't able to reproduce your problem with -I.
--
<a href="http://www.tuxedo.org/~esr/">Eric S. Raymond</a>
Men trained in arms from their infancy, and animated by the love of liberty,
will afford neither a cheap or easy conquest.
-- From the Declaration of the Continental Congress, July 1775.