build breaks when checkpoint unimplemented by arch

Nathan Lynch ntl at
Tue Jul 7 09:31:15 PDT 2009

Oren Laadan <orenl at> writes:
> On Tue, 7 Jul 2009, Nathan Lynch wrote:
>> Oren Laadan <orenl at> writes:
>> > That's what I tried initially, but the problem is that sigset_t may
>> > be defined differently for userspace - see /usr/include/asm/sigset_t.h.
>> > In fact, for x86_32, it it is different, defined as 'unsigned long' 
>> > (and NSIG defined as 32, so only 32 bits).
>> I noticed this, but I figured only the kernel definition was salient.
>> Apart from debugging checkpoint/restart, why would userspace need the
>> definition of struct ckpt_hdr_sigset?
> I expect user space tools to at least:
> - Assist in debugging c/r
> - Assist users in reporting problems with c/r (especially since they
>   themselves do not debug or hack)
> - Convert checkpoint images from one kernel version to another
> - Provide information about a checkpoint image, and even allow its
>   manipulation.  This can assist developers in debugging their programs
>   (e.g. to debug a crash you need to run a program for 30 minutes so it 
>   ets up its state; instead of repeatedly running it, you run it once, 
>   checkpoint, and then debug from a restarted version. A tool could 
>   allow you to peek/poke inside the checkpoint and even modify data in 
>   it).
> - Or a tool that converts a checkpoint image to a core dump so it
>   can be inspected with gdb.
> I'm pretty sure others will find other uses to it...

But I asked specifically about ckpt_hdr_sigset.

>> For that matter, why would userspace need the definitions of most of the
>> structures in checkpoint_hdr.h?  (Again, debugging purposes don't count:
>> ckptinfo or similar developer utilities can be included with the
>> kernel.)
> Keeping the checkpoint header format understandable by user space (and 
> immune to 32-64 variations) has been a requirement since day 1.

I guess I wasn't around that day.  It seems backwards to expose the
format of every checkpoint record in the ABI regardless of whether
plausible use cases exist.  Linux has a well-established pattern of
introducing interfaces without sufficient testing or documentation[1],
and I expect C/R will adhere to tradition.  Making the ABI obese in the
hope of anticipating every conceivable use will just provide more
opportunities to screw up.


More information about the Containers mailing list