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 [email protected]
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
[Index of Archives]
[Kernel Newbies]
[Netfilter]
[Bugtraq]
[Photo]
[Stuff]
[Gimp]
[Yosemite News]
[MIPS Linux]
[ARM Linux]
[Linux Security]
[Linux RAID]
[Video 4 Linux]
[Linux for the blind]
[Linux Resources]
