lkml.org 
[lkml]   [2008]   [Aug]   [14]   [last100]   RSS Feed
Views: [wrap][no wrap]   [headers]  [forward] 
 
Messages in this thread
    /
    Date
    From
    SubjectRe: [Devel] Re: [RFC][PATCH 1/4] checkpoint-restart: general infrastructure
    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
    restoring side.

    (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 ?


    \
     
     \ /
      Last update: 2008-08-14 10:15    [W:0.023 / U:0.324 seconds]
    ©2003-2016 Jasper Spaans. hosted at Digital OceanAdvertise on this site