Riley Williams wrote:
> [...]
> I can do that - then you'll have a script to be run on the target
> computer to get the configuration (mine), and a script to be run on
> the compiling computer to produce the relevant kernel and modules
> (yours).
Great !
> [...]
> Neither have I as I've only ever used ix86 systems. However, on the
> software level, I understand that `make bzImage` only applies to ix86
> based systems since the others don't have the stupid boot memory
> limitation that ix86 systems have.
Okay. Maybe it is more realistic to get all this done for i386 systems
first and AFTER that start worrying about other systems, as we both have
no experience with other architectures.
> Basically, I see the system working as follows:
>
> 1. My configuration script will produce a SysConfig file for the
> system it is run on. This will be an architecture-dependant
> script stored in arch/*/autoconfig and will produce a file
> with THREE types of lines in it:
>
> 1. Comments, being lines beginning with a '#' character.
>
> 2. AUTOCONFIG_* lines will be instructions to your compiler
> script to give it important information. Such lines will
> appear first in the output file. The following are typical
> examples of these lines:
>
> AUTOCONFIG_ARCHITECTURE=ix86
> AUTOCONFIG_DISTRIBUTION=RedHat
>
> 3. CONFIG_* lines will be those currently used in .config
> to state the configuration to be used.
>
> Note that the configuration produced by this tool will usually
> NOT include every possible option. Because of this, what it
> WILL do is to include every option it handles with lines of
> the last type, even if it is setting them to "n".
>
> 2. Your tool will read the AUTOCONFIG lines from the selected
> SysConfig file and use them to preconfigure itself to compile
> for the desired architecture, etc. Note that this implies that
> the compiling system is set up for cross-compilation if needed.
>
> If these settings are such that the desired result can not be
> produced on the compiling system, your tool will report the
> error and abort at this stage.
>
> 3. Your compilation tool will read in the selected SysConfig file
> produced by my tool, and will compare the settings therein to
> those in the config.in tree in the relevant kernel, noting that
> the options in the two files will probably not be in the same
> sequence, and it is also possible that there will be options
> listed in the SysConfig file that are not required by the tree
> conditionals in the config.in tree.
>
> 4. For any option not listed in the SysConfig file, and also for
> any option listed therein with an invalid value, your tool will
> ask the user for the desired setting, in the same order that
> they are listed in the config.in tree. Basically, it acts like
> a `make oldconfig` using the SysConfig file as the old setup.
>
> 5. When the above has been completed, your tool will verify that
> the user wishes to compile a kernel for that configuration, and
> if the users confirms such, will go ahead and compile it.
>
> Perhaps you could comment on the above scenario?
I see it this way:
1. CONFIGIGURE
a. Find out as much as possible about the system via autodetect.
This identifies only hardware components.
b. Complete these informations with some SIMPLE questions about the
system. E.g. if there was no sound card found ask if he really
hasn't
got one.
c. Write all this information in a file (e.g. systeminfo).
d. Use systeminfo and a database (maybe also a file, e.g. configdata)
to set as many options as possible and to identify options that can
be suggested to the user.
e. Ask the user about the suggested options.
f. Ask the user about options that are not system related.
g. Write the found set of options to a file (e.g. .config)
h. Let the user have a last look on all options in the old style if
everything is fine. So he can change some things. Maybe just for
experts ?
2. COMPILE
3. INSTALL
I was thinking that you work on 1a. I work on 2 and 3.
I think the really hard part will be 1d-g as it might become really
complex and it will decide if we fail or not on the whole part 1. It
should really simplify the configuration process otherwise it is
useless.
You could write the results in a file that could look like this:
# Config file form autoconfig
CPU=686
SERIAL=y
PARPORT=y
PCIBUS=y
SCSI=y
IDE=y
SOUND=n
BIOS=AWARD .....
ETHERNET=n
PCICARD="Soundblaster PCI64V"
ISACARD="NE 2000"
AGPCARD="ASUS 3400 TNT"
VLBCARD=
If we aren't able to do 1d-g this STILL would be a really good tool to
get some informations about your system, not only for compiling a
kernel.
There might be already some tools out there that we could use instead of
writing our own one.
What do you think ?
Bye,
Steffen
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/