[lkml]   [2002]   [Oct]   [22]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: Son of crunch time: the list v1.2.
    Jeff Garzik <> writes:

    > > 13) Kexec, luanch ELF format linux kernel from Linux (Eric W. Biederman)
    > >
    > Useful, but at the same time not many people will use this I think. It may need
    > to live as a patch for a while, if not for a long while...

    Hmm. 2+ years is not enough?

    A couple of comments.

    The limitation to the ELF file format is long gone, (so the summary is
    incorrect). sys_kexec can launch any random kernel, it just needs an
    appropriate user space program that understands the format. kexec
    bzImage works, and I suspect kexec could even start booting windows
    from the boot sector of a hard drive.

    The code has been looked at, and discussed by the kmonte, and bootimg
    authors, and the kexec interface has not been found to be a problem.
    Except for tracking kernel interface changes the code really has not
    needed to change in quite a long while.

    The biggest challenge right now is to track down the strange and
    mysterious failures caused by driver or BIOS bugs. Kexec is
    inherently open to a bug anywhere in the system causing it to fail.
    The development work consists of writing code, and inventing
    techniques to track down those mysterious failures. Kernel debuggers
    don't work when you don't have a running kernel.

    All of this is generic kernel stabilization work, and it sounds to me
    like a good complement to the upcoming 2.5.x stabilization efforts.

    A smallish user base may be a good argument against it. But I unless
    I have miscounted there are quite a few people playing with bootimg,
    and kmonte, not to mention the earlier versions of kexec.

    To do things right sys_kexec needs access to call device_shutdown, and
    the reboot notifier chain. The latter is available only as a static
    variable in kernel/sys.c. And neither of them are exported from the

    Keeping sys_kexec out of the kernel seems to encourage half baked,
    half debugged implementations that just work for their authors, and
    are limited to what it is easy to do as a module.

    Putting in the sys_kexec patch in the kernel will certainly discourage
    hacks in the code, and encourage those last few strange mysterious
    failures to be tracked. Plus it will put pressure on driver
    maintainers to fix various bugs in their code. And the patch is
    not very intrusive at all so I fail to see a downside except bloat.

    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to
    More majordomo info at
    Please read the FAQ at

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