Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > > > Serge E. Hallyn wrote: > > Quoting Oren Laadan (orenl@xxxxxxxxxxxxxxx): > >> Hi Gordon, > >> > >> Serge E. Hallyn wrote: > >>> Quoting Ralph-Gordon Paul (Ralph-Gordon.Paul@xxxxxxxxxxxxxxxxxx): > >>>> 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@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
