Re: [RFC][PATCH 0/2 -mm] kexec based hibernation

["Huang, Ying" <ying.huang@intel.com>]

On Mon, 2007-08-27 at 13:15 +0000, Pavel Machek wrote:
> Hi!
> 
> > >> > 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. 
> > >> 
> > >> And, I think we can do more in bootloader. Such as we can prepare
> > >> two
> > >
> > > Yes, that would be nice.
> > >
> > > It will mean quite a bit of work, but I guess it should be the long
> > > term goal. Loading restore kernel directly from bootloader means:
> > >
> > > 1) it is fast -- no need to boot another kernel
> > >
> > > 2) it is "classical" way of doing things
> > >
> > > On the other hand, we loose flexibility that way:
> > >
> > > 1) it locks you onto one bootloader
> > >
> > > 2) you no longer have userland there to do uncompression, decryption,
> > > etc..
> > 
> > True although for the uncompression and decryption those aren't exactly foreign
> > requirements for bootloaders.
> 
> Well, uncompression yes, but crypto? What is that, some kind of
> trusted computing thingie?
> 
> We do RSA for uswsusp, that may be a bit of problem for a bootloader,
> but I'm glad bootloaders are bloated already :-).

As far as I know, the grub 2.0 uses a modular implementation scheme.
That is, every OS loader (Multi-boot, Linux, FreeBSD etc), partition
table, file system is implemented as a module, and these modules can be
statically linked into the final image.

So I think the hibernation image loading can be implemented in grub 2.0
in a manageable way. :)

Best Regards,
Huang Ying