build breaks when checkpoint unimplemented by arch
ntl at pobox.com
Tue Jul 7 09:31:15 PDT 2009
Oren Laadan <orenl at cs.columbia.edu> writes:
> On Tue, 7 Jul 2009, Nathan Lynch wrote:
>> Oren Laadan <orenl at cs.columbia.edu> 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
> - 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
> 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,
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