Messages in this thread | | | Date | Thu, 15 Jul 1999 15:34:27 +0100 (GMT) | From | Riley Williams <> | Subject | Re: script for compiling the kernel |
| |
Hi Steffan.
>> 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/
| |