lkml.org 
[lkml]   [2000]   [Jan]   [10]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    SubjectRe: [Semi-OT] hot-swapping kernels
    From
    Date
    almesber@lrc.di.epfl.ch writes:

    > Matthias Andree wrote:
    > > I think a kernel as second-stage bootloader is overkill.
    >
    > Functionality-wise, yes. Maintenance-wise, probably not. Let me explain:
    > the complexity of the boot process is gradually increasing over time.
    > One source of complexity is added functionality in the Linux kernel, e.g.
    > RAID. Another source of complexity are more complex setups people want to
    > build, e.g. see the tftp thread in linux-kernel.

    As has been laid out, people can use initrds for this.

    > Mirroring major new kernel functionality in a boot loader tends to be a
    > time-consuming business and always contains the risk of version drift.
    > Also, if a feature is missing in the boot loader, it will be hard to
    > add by users who need it.

    I am aware of the maintenance issue. This is however a design flaw.

    I have seen some i386 OSs, NetBSD 1.4.1, OpenBSD 2.6, Linux 2.0/2.2,
    DOS6.22/Win95B, WinNT4, Solaris 2.6 -- each have a different boot
    sequence to get the kernel into RAM and kick it into boot.

    While I don't expect to circumvent chainloaders for commercial OS's (and
    I don't really care), if there was a carefully chosen sequence that *BSD
    and Linux shared, that would constitute quite a gain.

    > On the other hand, a Linux kernel is implicitly capable of handling
    > everything one might successfully throw at a Linux kernel. Somebody
    > who is able to make use of a given feature in a "regular" system
    > should also find it quite feasible to make use of it from the second
    > stage. In particular, normally, no modification of the boot loader
    > will be necessary.

    Yes. Still, you need "old-fashioned" simple boot-loaders, be they
    filesystem-aware (GRUB, SYSLINUX), be they not (LILO), be they TFTP
    based or whatever, to get the second stage bootloader into RAM, whatever
    its name and origin. No matter if it's called GRUB or LINUX, you cannot
    simply boot that kernel from a SoftRAID, you cannot currently boot from
    reiserfs either.

    > Of course, using a little Linux system as a second stage loader may
    > appear excessive. One issue can be space. On most regular PCs, there
    > is sufficient storage space nowadays to afford this overhead. There
    > will always be exceptions where space is highly critical (e.g.
    > embedded, diskless, etc.) so the current, more streamlined boot
    > process needs to continue to work.

    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.

    Even a simple stripped-down linux kernel that can do nothing more than
    bring buses, SCSI/IDE and filesystems in will have some 50 kB which
    means you already need what GRUB calls a stage1.5 loader.

    > Another issue can be time. That's why I think it will be necessary
    > that the first kernel can pass the results of bus scans etc. directly
    > to the second kernel. The latter can then skip this process, or
    > possibly initiate a new scan in the background (e.g. if the second
    > kernel may be able to see more devices), while already proceeding
    > with the information passed from the other kernel.

    Since the internal presentation of data varies over kernel versions, you
    will most certainly impose further restrictions on the boot sequence
    such as "2nd stage must be compiled along with the kernel" - exactly the
    opposite of your aim. If you bring data into a generic format, you will
    need additional layers in the kernel -> code bloat. That's ot what you
    want either.

    The biggest delays on my machine come from the BIOS boot sequences, not
    from the kernel itself booting. So, it's not the time issue for me.

    > > I think people should rather work merging the advantages of LILO and
    > > those of GRUB, to get a DECENT bootloader.
    >
    > Don't forget all the non-i386 architectures. Also, there are several
    > specialized boot loaders on i386 alone (e.g. SYSLINUX), which may have
    > to track some changes too.

    So the solution is a stable, universal booting sequence with a defined
    API. I haven't looked deeper into the "multiboot standard" that comes
    with GRUB. Having a carefully-designed booting interface will probably
    get us rid of the bootloader maintenance issue.


    As for other architectures: I have used SILO on a Sparc32, which is file
    system aware just like GRUB is. This is a big advantage since it
    essentially keeps your machine booting even if you play around with
    kernels and forget about /sbin/lilo which happens every now and then.

    --
    Matthias Andree

    Hi! I'm the infamous .signature virus!
    Copy me into your ~/.signature to help me spread!

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

    \
     
     \ /
      Last update: 2005-03-22 13:55    [W:0.025 / U:66.868 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site