>> The attached bash script is how I would start doing that...
> Looks good. Do you want to continue this ? That would be great !
> I will be busy for a while improving mkkrl in its simple version
> without autodetection. So, when you start the autodetection part
> we could combine both in a few weeks. What do you think about it?
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).
> Besides, in my /proc/ioports you have to look for 'parport' not 'lp'.
That I couldn't check, as the system I was on when I developed that
script didn't have the parallel port system compiled in, so I had to
guess...
>> How does one deal with the fact that the settings that work on
>> one configuration do NOT work on another?
>> As an example of this, take my two systems. I have a USR Sportster
>> 33k6/VoiceFax modem, and I need to set it up DIFFERENTLY for the
>> two systems. OK, both have it set for COM3 at 0x3E8, but on one, I
>> need to set it to use IRQ5 and on the other I need to set it to
>> use IRQ2/9.
> There will be always some settings that have to be done
> manually, but at least you could find out, which are the
> POSSIBLE values and only ask to choose from them.
True.
> In this special case: Do you have an internal modem?
It is an internal modem, yes.
> I don't know much about the internal ones. But as far as I know
> most of these devices are registered one way or the other in
> your BIOS and we should be able to get these informations from
> there and NOT from the user.
In this case, the modem is an ISA non-PnP internal model, and the
conflict arises because the modem can only access the low interrupts,
of which 2/9 and 5 are the only free ones. Both systems also have
network adapters in them, both being ISA-based NE2k clones, and both
are correctly auto-detected by the probe logic. However, one is set
(through non-jumpered means) to use IRQ5 and the other (through the
same non-jumpered means) to use IRQ2/9 and I've no idea how to change
that. What I'd like is to get both network cards using IRQ2/9 and then
just leave the modem using IRQ5 but I've been unsuccessful in doing
so...
>>>> One other thought - is your script going to be i386 only?
>>> No, as long as there is no real good reason for that I want to
>>> keep it generic.
>> Good - but note that there will be (probably large) parts of it
>> that are architecture-dependant - the processor model detection
>> for starters...
> When it becomes to hard I will keep in mind that other people
> might extend the script for the other ports and stick to i386.
> By the way. I haven't got ANY idea how things work on other
> architectures on hardware level ...
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.
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?
Best wishes from Riley.
+----------------------------------------------------------------------+
| There is something frustrating about the quality and speed of Linux |
| development, ie., the quality is too high and the speed is too high, |
| in other words, I can implement this XXXX feature, but I bet someone |
| else has already done so and is just about to release their patch. |
+----------------------------------------------------------------------+
* ftp://ftp.MemAlpha.cx/pub/rhw/Linux
* http://www.MemAlpha.cx/kernel.versions.html
-
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/