I've got a question about the ABI that would be created
I see two possible areas that could be considered an ABI
1. control of the C/R process
This is very clearly a userspace ABI, to be figured out and locked down
like any other ABI
2. the details of how things are stored and added back into a system
This is not as clear. at one extreme, this could be like the module
interface, (the checkpointed image is only guaranteed to work on a new
system with a kernel compiled with the same config options as the system
it was checkpointed from). At the other extreme, this could be something
that allows you to ckeckpoint an image on 2.6.40 and restore it on 2.6.80.
Or it could be something in between.
I don't see any way that it is sane to make the C/R image defiition and
interface (#2) be an ABI that is guaranteed to never change without
hurting future kernel development (exactly the type of things that Davide
is worried about above), but what sort of guarantee are people interested
in?
is it enough to sa that it must be the same kernel version compiled with
the same options? (or at least the same options for some list of things
that matter, most device drivers probably would not matter for example)
or would you need compatibility across all compile options for a kernel
release?
would you require compatibility between 2.6.x.y and 2.6.x.z?
would you require compatibility between 2.6.x and 2.6.x+n (for some value
of n)?
is this something that could go in with the weakest guarantee initially,
and then as everyone is more comfortable with it, start extending the
guarantee (and as-needed adding code to the kernel to maintain
compatibility with old images)?
would you require compatibility between 2.6.x and 2.6.x-n?
David Lang
--
