[lkml]   [2002]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
Messages in this thread
    SubjectRe: kexec (was: [lkcd-devel] Re: What's left over.)
    On Thu, 2002-11-07 at 11:32, Andy Pfiffer wrote:
    > On Thu, 2002-11-07 at 00:50, Eric W. Biederman wrote:
    > > In staging the image we allocate a whole pile of pages, and keep them
    > > locked in place.

    > Just an idea:
    > Could a new, unrunnable process be created to "hold" the image?
    > <hand-wave>
    > Use a hypothetical sys_kexec() to:
    > 1. create an empty process.
    > 2. copy the kernel image and parameters into the processes' address
    > space.
    > 3. put the process to sleep.
    > </hand-wave>

    A further refinement to the above:

    1. make sys_kexec() a blocking call. The caller reads the image into
    their address space prior to making the call, and passes the same kind
    of information (number of segments, segment pointer, etc.) to the
    syscall in the same manner. Then, it sets a well-known global variable
    that means "there is a kexec image available", and then blocks.

    2. add code to sys_reboot() under a CONFIG_KEXEC to check the global
    variable in [1) above], and if a kexec image is available, wake the
    process in [1) above].

    3. the reawakened sys_kexec() then proceeds to copy-in and lay down the
    new image in memory, shutdown the devices, and go.

    I'm still pondering the kexec-ish reboot after panic() with this kind of
    mechanism. Ah well, it's just an idea.


    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:5.236 seconds]
    ©2003-2017 Jasper Spaans. hosted at Digital OceanAdvertise on this site