Messages in this thread | | | Date | Thu, 18 Nov 2010 15:25:33 -0500 | From | Oren Laadan <> | Subject | Re: [Ksummit-2010-discuss] checkpoint-restart: naked patch |
| |
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.
| |