On 11/17/2010 05:17 PM, Matt Helsley wrote: > On Wed, Nov 17, 2010 at 12:57:40PM +0100, Tejun Heo wrote: >> Hello, Oren. >> >> On 11/07/2010 10:59 PM, Oren Laadan wrote: <snip> >>> Or we could use linux-cr for that: do the c/r in the kernel, >>> keep the know-how in the kernel, expose (and commit to) a >>> per-kernel-version ABI (not vow to keep countless new individual > > Oren, that statement might be read to imply that it's based on > something as useless as kernel version numbers. Arnd has pointed out in the > past how unsuitable that is and I tend to agree. There are at least two > possible things we can relate it to: the SHA of the compiled kernel tree > (which doesn't quite work because it assumes everybody uses git trees :( ), > or perhaps the SHA/hash of the cpp-processed checkpoint_hdr.h. We could > also stuff that header into the kernel (much like kconfigs are output from > /proc) for programs that want the kernel to describe the ABI to them. BTW, it's the same for userspace c/r: for the same set of features, the format (ABI) remains unchanged. Adding features breaks this and a new version is necessary, and conversion from old to new will be needed. Moreover, supporting a new feature in userspace means adding the proper API/ABI in the kernel, including refactoring etc, which is even harder than adding the support for it in linux-cr. Oren. _______________________________________________ Containers mailing list Containers@xxxxxxxxxxxxxxxxxxxxxxxxxx https://lists.linux-foundation.org/mailman/listinfo/containers
