lkml.org 
[lkml]   [2010]   [Nov]   [7]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
/
Date
From
SubjectRe: [Ksummit-2010-discuss] checkpoint-restart: naked patch
On Sun, 7 Nov 2010, Davide Libenzi wrote:

> Please, do not compare things like single file systems, drivers, or
> otherwise fairly isolated components, with this "thing".
> This thing touches a freaky-large number of subsystems, effectively
> adding a glueage between them, which can might end up causing problems
> (and/or restrict design choices) in the future.

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


\
 
 \ /
  Last update: 2010-11-08 03:35    [W:0.073 / U:1.800 seconds]
©2003-2020 Jasper Spaans|hosted at Digital Ocean and TransIP|Read the blog|Advertise on this site