[Devel] Re: [PATCH 3/7] make CONFIG_CHECKPOINT dependonCONFIG_CHECKPOINT_SUPPORT
Serge E. Hallyn
serue at us.ibm.com
Tue May 12 09:39:44 PDT 2009
Quoting Oren Laadan (orenl at cs.columbia.edu):
>
>
> Serge E. Hallyn wrote:
> > Quoting Oren Laadan (orenl at cs.columbia.edu):
> >> Hi Gordon,
> >>
> >> Serge E. Hallyn wrote:
> >>> Quoting Ralph-Gordon Paul (Ralph-Gordon.Paul at uni-duesseldorf.de):
> >>>> Ah okay sorry, i used this version: http://git.ncl.cs.columbia.edu/?p=linux-cr.git;a=shortlog;h=refs/heads/ckpt-v15
> >>>>
> >>>> Is this the official place to download the up to date version ?
> >> ckpt-v15 branch per-se is a snapshot of the patchset as it was released.
> >>
> >> ckpt-v15-dev is the development branch that is based on ckpt-v15, and is
> >> probably what you want to use.
> >>
> >> the userspace utilities are in the matching v15-dev in 'user-cr.git'.
> >>
> >>>> -Gordon
> >>> Hi Gordon,
> >>>
> >>> yes, and you were right about needing compat vdso. Sorry about the
> >>> inconvenience (since it was my patch). I was just saying that since
> >>> Oren has added the underlying code for moving vdso around, there is no
> >>> reason why we shouldn't complete that support (with 1 line of code)
> >>> allowing us to remove the dependency on CONFIG_COMPAT_VDSO.
> >> True, no need to keep that dependency. Will remove.
> >>
> >> Note, however, that we still don't handle the case where the contents of
> >> the VDSO page(s) differ between checkpoint and restart time... So it's
> >> on the todo list to at least detect that the format changed.
> >
> > sigh - yeah, and we still haven't decided how to cleanly solve that,
> > have we... (apart from some arch-specific memcmp template/map that
> > compares the code and not data...)
>
> Heh .. I thought we outlined a suitable solution:
>
> * On checkpoint, save the contents of the VDSO page(s), or their hash,
> but not including any dynamic data exported by the kernel. The VDSO
> contents themselves should be a shared object.
>
> * On restart, compare the contents, or their hash, with the local
> kenrel; If there is a match -- all well. If not - need to provide
> some compatibility code in place of the original VDSO.
>
> The gory details .. oh well ...
yeah, the details, that's what I was sighing about :)
-serge
_______________________________________________
Containers mailing list
Containers at lists.linux-foundation.org
https://lists.linux-foundation.org/mailman/listinfo/containers
More information about the Devel
mailing list