How do we handle autoconfiguration?

How do we handle autoconfiguration?

[Eric S. Raymond]

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/

Re: How do we handle autoconfiguration?

[Kai Henningsen]

[CC: list drastically trimmed]

esr@snark.thyrsus.com (Eric S. Raymond)  wrote on 26.12.00 in <200012262313.eBQNDBi07719@snark.thyrsus.com>:

> 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
-
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/

Re: [KBUILD] How do we handle autoconfiguration?

[Giacomo A. Catenazzi]

"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.
-
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/

Re: [KBUILD] How do we handle autoconfiguration?

[Giacomo A. Catenazzi]

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
-
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/

Re: [KBUILD] How do we handle autoconfiguration?

[Eric S. Raymond]

Giacomo A. Catenazzi <cate@student.ethz.ch>:
> 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.
-
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/

How do we handle autoconfiguration?

[Eric S. Raymond]

I wrote:
>Giacomo, what's the state of your project?

Sigh, I got an address-invalid bounce from Giacomo.  Looks like he 
may have fallen off the net.
--
						>>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/

Re: [KBUILD] How do we handle autoconfiguration?

[Giacomo A. Catenazzi]

"Eric S. Raymond" wrote:
> 
> I wrote:
> >Giacomo, what's the state of your project?
> 
> Sigh, I got an address-invalid bounce from Giacomo.  Looks like he
> may have fallen off the net.

I still receive mails!
Maybe try cate@debian.org [better administrators, better software :-)]

	giacomo
-
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/

Re: [KBUILD] How do we handle autoconfiguration?

[Michael Elizabeth Chastain]

esr> # PROCESSOR is string valued; we capture stdout from the probe
esr> derive PROCESSOR from "myprobe1.sh"
esr> 
esr> # FOOFEATURE is boolean; we look at the return status from myprobe2.py 
esr> derive FOOFEATURE from "myprobe2.py"

I think this is cool.

esr> (kbuild people, this is one reason I want ifdefs gone from the
esr> makefiles.  The autoconfigurator, whether it's Giacomo's or not,
esr> should be able to pass FOO=n to tell CML2 that a given feature is
esr> definitely not present.)

Yeah, we have to make an essential transition from 3-valued logic
("y"/"m"/"n" in some contexts and "y"/"m"/NULL in other contexts) to
4-valued logic ("y"/"m"/"n"/NULL).

Michael
-
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/