Messages in this thread | | | Date | Thu, 18 Nov 2010 15:41:20 -0500 | From | Oren Laadan <> | Subject | Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch |
| |
On 11/07/2010 09:32 PM, david@lang.hm wrote: > 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?
Agreed. The guarantee should be to specific kernels, in a sense (see Matt's post in this thread 11/17).
The image format is tied to "set of features supported" (which boils down to something like kernel version). The format is constructed in a modular way such that most new features can be added without breaking old format. For the rare cases that they do, conversion can be done in userspace in a straightforward manner. (All you need is convert from N to N+1).
> > 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?
We don't "require" compatibility. The compatibility is defined per object (type) in the image format. New objects need not break compatibility. Changes to objects are very rare; and when they happen they "bump" the version. This can help avoid issues related to kernel configs/options. Restarting an image incompatible with a particular kernel will fail, adjustments should be done by userspace filtering.
Thanks,
Oren.
| |