[Devel] Re: [RFC][PATCH 1/4] checkpoint-restart: general infrastructure
xemul at openvz.org
Thu Aug 14 01:09:00 PDT 2008
Oren Laadan wrote:
> Dave Hansen wrote:
>> On Fri, 2008-08-08 at 11:46 +0200, Arnd Bergmann wrote:
>>> On Friday 08 August 2008, Dave Hansen wrote:
>>>> + hh->magic = 0x00a2d200;
>>>> + hh->major = (LINUX_VERSION_CODE >> 16) & 0xff;
>>>> + hh->minor = (LINUX_VERSION_CODE >> 8) & 0xff;
>>>> + hh->patch = (LINUX_VERSION_CODE) & 0xff;
>>> Do you rely on the kernel version in order to determine the format
>>> of the binary data, or is it just informational?
>>> If you think the format can change in incompatible ways, you
>>> probably need something more specific than the version number
>>> these days, because there are just so many different trees with
>>> the same numbers.
>> Yeah, this is very true. My guess is that we'll need something like
>> what we do with modversions.
> Exactly. The header should eventually contain sufficient information
> to describe the kernel version, configuration, compiler, cpu (arch and
> capabilities), and checkpoint code version.
Sorry for late response - I was on vacation till Wednesday.
I am opposed against having *explicit* information about the kernel
configuration inside the image.
I see this like we store object images in a file, and these images do
*not* change depending on the .config. But instead of this, at the time
of restore we may *only* detect whether we can restore this type of
object or not.
E.g. consider we are saving a container image on ipv6 node and trying
to restore from it on the one without the ipv6. In that case we *may*
have some object of for example CKPT_IPV6_IFA type of CLPT_IPV6_SOCK_INFO
and fail the restoration process when finding such in an input file. But
what we should *not* do is to write any information about whether we had
the CONFIG_IPV6 turned on on the dumping side and check for this on the
(Sorry, if this question is already settled, but the discussion thread
built by my mailer is a bit messy, so I suspect I could miss some part
of the threads)
> How would you suggest to identify the origin tree with an identifier
> (or a text field) in the header ?
More information about the Containers