Re: checkpoint/restart

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:..
:code now uses the above suggested semantics. Instead of directly calling
:ckpt_checkpoint the code registers handle_ckpt for SIGCKPT (arbitrarily
:defined as 42) and then sends itself SIGCKPT. The function handle_ckpt is
:defined as follows:

    Patch set 6 works like a charm!  If you get stuck on the file handle
    issue I would be pleased to help out there.  Also note that you should
    not need to use any ELF/EXEC code at all except for the saved register
    state once you record the file descriptor state and (if not already
    recorded) related descriptor mappings, the restore code would be 
    image based.

    If you want to get the kernel hook in for the default signal / module
    support and add the SIGCKPT and SIGCKPTEXIT signals to sys/signal.h,
    We can commit that early so people doing ongoing testing of the module
    do not have to patch their kernels.

    FreeBSD-5 has added signal 32, so I recommend we add this to sys/signal.h:

#if __BSD_VISIBLE
#define SIGTHR          32      /* Thread interrupt (FreeBSD-5 reserved) */
#define SIGCKPT		33	/* check point and continue */
#define SIGCKPTEXIT	34	/* check point and exit */
#endif

    I also recommend that your ckpt_checkpoint() syscall be given an
    additional flags argument for future augmentation.  e.g. for 
    'pushed' migrations to virtual targets: ckpt_checkpoint(-1, CKPT_CPU|...),
    or telling it to ignore certain failure cases like sockets and tty's
    (CKPT_NO_SOCKETS, CKPT_NO_PGRP_TTYS), or to request future retention of
    detached files through their link counters (CKPT_HOLD_LINKCNT), and
    other things.  

    The retval from ckpt_checkpoint and the flags argument to ckpt_restore()
    could all use the same flag set (e.g. so in the restore code you would
    pass CKPT_RETURN instead of THAW_RETURN, and ckpt_checkpoint() would
    return a set of CKPT_ flags (and still return -1 on failure)), etc.

    Just brainstorming here!

							-Matt