Kip Macy kmacy at
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 mailing list