lkml.org 
[lkml]   [2007]   [Aug]   [27]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [RFC][PATCH 0/2 -mm] kexec based hibernation
    On Mon, Aug 27, 2007 at 02:18:49PM +0800, Huang, Ying wrote:

    [..]
    > >
    > > If one compiles the kernel C to boot from reserved memory area (subset
    > > of memory area used by kernel B), then I can skip the step of kexecing
    > > from C to D? (COFIG_PHYSICAL_START)
    >
    > Yes. I think so.
    >
    > > Alternatively, can we give hint to kernel C to run from a specified address
    > > at run time with the help of command line parameters. What I mean boot-loader
    > > can load the kernel at any address, but kernel will move itself to run
    > > from a different location depending on command line parameter. For example,
    > > let say kernel_run_addr = 0x1000000. This parameter will tell the kernel
    > > to move itself to 16MB address and run from there. I think it can be made
    > > to work with little work in existing setup of relocatable kernel.
    > >
    > > Kernel run address can be put by some user space script which will save
    > > the hibernated image of original kernel. So after saving the /proc/vmcore,
    > > script can modify the boot loader config file to append the right
    > > command line to the kernel (kernel_run_addr).
    > >
    > > After hibernation, user will shutdown/reboot. Next time the kernel boots
    > > it will load at 16MB addr (because of kernel_run_addr) and then it can
    > > restore the previously saved image.
    > >
    > > We shall have to get rid of (kernel_run_addr) parameter from command
    > > line while resuming. One can restore the image (krestore) and then edit
    > > the boot loader config file to get rid of command line param, kernel_run_addr.
    > >
    > > In this scheme, with the help of relocatable kernel, we can use a single
    > > kernel for everything. (A, B, C, D). We will also avoid additional kexec
    > > from kernel C to kernel D.
    > >
    > > I think in the long run we shall have to work out so that a user does
    > > not have to maintain multiple kernels.
    >
    > Only one relocatable kernel image is needed. In fact, I use one
    > relocatable kernel image in testing during development.
    >
    > > Does this make sense?
    >
    > Yes, this is a sensible optimization. But I think it may be better to
    > make bootloader load kernel D directly into a specified memory location.
    > For example, we can add a option to "kernel" command of grub.
    >

    IIUC, you mean a command line option which is parsed by boot-loader and
    then boot-loader loads the kernel at user specified address?

    I think it might not be a very good idea as hibernation becomes boot-loader
    dependent scheme. How many boot-loaders will one modify and hibernation
    will not work with older versions of boot-loader.

    I think it is better to make kernel relocate to user specified address and
    keep hibernation mechanism independent of specific boot-loader(grup, lilo,...)
    and boot-loader version.

    Thanks
    Vivek
    -
    To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
    the body of a message to majordomo@vger.kernel.org
    More majordomo info at http://vger.kernel.org/majordomo-info.html
    Please read the FAQ at http://www.tux.org/lkml/

    \
     
     \ /
      Last update: 2007-08-27 08:57    [W:4.762 / U:0.036 seconds]
    ©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site