Re: [PATCH 0/2] Kexec jump: The first step to kexec base hibernation

[david]

On Mon, 16 Jul 2007, Rafael J. Wysocki wrote:

> On Sunday, 15 July 2007 21:33, david@xxxxxxx wrote:
> > On Sun, 15 Jul 2007, Rafael J. Wysocki wrote:
> >
> > > On Saturday, 14 July 2007 23:34, david@xxxxxxx wrote:
> > > > On Sat, 14 Jul 2007, Rafael J. Wysocki wrote:
> > > >
> > > > > On Saturday, 14 July 2007 09:51, david@xxxxxxx wrote:
> > > > > > On Fri, 13 Jul 2007, Rafael J. Wysocki wrote:
> > > > > >
> > > > > > > > since people are complaining about the amount of ram that a kexec kernel
> > > > > > > > would take up I'm assuiming it's somethingmore complex then just a bitmap
> > > > > > > > of all possible pages.
> > > > > > >
> > > > > > > No, it's just bitmaps, AFAICS, and the complaints are a bit overstated, IMO. ;-)
> > > > > >
> > > > > > 1 bit for each 4k means 1m bits for 4g of ram, or 128k of bitmaps, growing
> > > > > > up to 1m of ram used for 32G of ram in the system. I guess this isn't bad
> > > > > > as long as it doesn't need to be contiguous for the new kernel to access
> > > > > > it.
> > > > > >
> > > > > > ok, that makes it a pretty trivial thing to work with. I just need to
> > > > > > learn how to find the bitmaps.
> > > > >
> > > > > They are created on the fly before the hibernation.  The format is described in
> > > > > kernel/power/snapshot.c .
> > > >
> > > > I'll look through this file, but the format of this is an abi/api to the
> > > > userspace and should be documented outside of the code.
> > >
> > > Nope.  The user space need not know anything about the image contents.
> > >
> > > The current implementation of the user space tools use the knowledge of the
> > > image header format, which is given by 'struct swsusp_info', defined in
> > > kernel/power/power.h .
> >
> > there are a couple factors here.
> >
> > 1. this needs to remain the same across different kernel versions.
>
> Not exactly.  Whatever is after the image header may change at any time and
> the user space should not rely on that not changing.  The header itself is a
> (slightly) different matter.

ok, more precisely

an image of one kernel version should be able to be fed into /dev/snapshot 
of another kernel version and work.

that's what I was meaning about it needing to be the same across different 
kernel versions

> > 2. this may or may not be created by userspace tools
>
> Well, the image header is not created by userspace tools and only read the
> image size from it.

it's not today, but maby it should be.

in the kexec approach there's nothing happening here that a perl script 
couldn't do perfectly well. it's reading a bitmap from somewhere, and 
based on that bitmap it creates a header and then reads chunks from 
/dev/oldmem or /dev/mem and writes the results somewhere (to a device, or 
a network or a userspace compress program, or ...)

> > both of these tend to imply that this is an interface to the world and
> > needs to be documented and stable.
>
> Well, it should be documented, but currently there's only one implementation
> of the userland tools and the authors of these know the format. ;-)

true today, but as the pieces get simplified and documented other 
implementations could exist.

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