Re: checkpoint/restart

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:I hope this isn't a stupid question, but how do I get the inode/dev_t for
:binary of the process itself? I'm sure I can find it, but you probably
:know off hand.

    There are two ways.  The binary itself is stored in the process 
    structure as p_textvp.  You can perform a stat on the vnode (I forget
    the VOP_ that does that).  But this is deficient for a number of
    reasons.

    A much better way is to access the related file via the VM map.  The
    VM objects making up the map will be OBJT_DEFAULT, OBJT_SWAP, OBJT_VNODE,
    OBJT_DEVICE, or OBJT_PHYS.  Don't worry about DEVICE and PHYS.  A 
    VM object that is DEFAULT or SWAP represents anonymous memory which
    the core presumably already saves (?).  A VM object that is OBJT_VNODE
    represents a portion of a mapping from a file (which may or may not have
    an associated file descriptor.  In the case of the binary and any shared
    libraries it will not have a descriptor).  OBJT_VNODE VM objects have a
    field through which you can get at the vnode pointer.

    So, basically you would scan the vm_map_entry list of the process via
    its p_vmspace and vm_map to get the image of the entire process, saving
    the anonymous memory portions (which represent both anonymous memory
    and dirty COW'd pages.. presumably the core code does this for you),
    and you record the file handle info for the vnode-backed portions.

:I'll see if I can't get that working by tonight. There are couple of open
:questions for non-checkpoint-aware apps. What should the checkpoint be
:called and where should it be put? Those should probably both be sysctls,
:but for the moment I think ckpt.<pid> is a reasonable name, and the
:current working directory is a reasonable place.

    I'd put it in kern/kern_sig.c, near psignal().  Call it whatever you
    like, e.g. register_ckpt_vector(funcptr).

					-Matt
					Matthew Dillon 
					<dillon@xxxxxxxxxxxxx>