kmacy at fsmware.com
Fri Oct 10 21:21:05 PDT 2003
> 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.
To be truly general I could just pass a structure (as stat should have)
and the structure's size. Or is that just gross?
> 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.
That would be easy enough to add, but can you give an example of where
that could be useful?
More information about the Kernel