>> I'd appreciate if the standard bootstrapping sequence was less
>> size-sensitive like it is now. LILO is extremely fragile, the kernel
>> itself must not exceed a certain size in order to boot. These are
>> limitations today.
>
>I have to look into this. So far I'm not sure of the alleged size
>limitation of LILO is for real or if it's other things in the system
>breaking.
Last time I looked (early last year) the limit was being imposed more
by the BIOS tending to be unable to handle addresses greater than 1024
cylenders.
I like a more SGI approach -
a. A minimal loader (BIOS) to load a lilo (new lilo -> nlilo for the moment)
b. nlilo load a more extensive loader capable of handling the full
range of disk addresses, and multiple file systems and multiple
controlers.
c. the extensive loader then loads the real kernel from whatever
device/file specified.
d. the BIOS boot device would not have to be the same the kernel
resides on (ie. boot IDE disk for nlilo, which then boots a
SCSI (or other) controller the BIOS doesn't understand.
The only time the nlilo would be replaced would be when
1. boot filesystem type is unknown
2. boot controller type is unknown
The advantages:
1. This separates the block mapping from having to be rebuilt on each
kernel build.
2. It can make a large amount of configuration information available.
3. It eliminates the 1024 cylender limit.
The disadvantages:
1. Theres one more step in installation
2. Another development cycle for supporting drivers
Disadvantage (2) could be handled by using an absolutely minimal kernel
- no scheduling, no multiuser support, full file system support
Might need a 1-2MB filesystem (DOS?) to hold everything... that might
even allow loadable modules as a rescue system. That would only need
a way to load the new kernel into physical memory and start it.
ummm. this is starting to sound too complicated. I do like the SGI
way of using SASH (stand alone shell) to boot the real kernel though.
-------------------------------------------------------------------------
Jesse I Pollard, II
Email: pollard@navo.hpc.mil
Any opinions expressed are solely my own.
-
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/
This archive was generated by hypermail 2b29 : Sat Jan 15 2000 - 21:00:22 EST