build breaks when checkpoint unimplemented by arch
orenl at cs.columbia.edu
Tue Jul 7 07:58:26 PDT 2009
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...
> 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.
> > Moreover, if you include <asm/sigset.h> in checkpoint_hdr.h, which is
> > also included by userspace, you get lots of compilations warnings,
> > because of other stuff included from the kernel's asm/sigset.h that
I meant: asm/siginfo.h
> > isn't supposed to be included by userspace.
> Can you provide examples of such warnings? Are you building against
> "sanitized" kernel headers (make headers_install) or using them in
More information about the Containers