dillon at apollo.backplane.com
Fri Oct 10 23:42:38 PDT 2003
: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
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).
<dillon at xxxxxxxxxxxxx>
More information about the Kernel