Re: file handles in checkpt and sys_checkpoint

[Matthew Dillon <dillon@xxxxxxxxxxxxxxxxxxxx>]

:Hi, friends.  I love DragonFly, I do.  Well done.  Question about
:checkpointing.
:
:There's a bit of a catch-22 when using sys_checkpoint().  The file
:descriptor which is passed into sys_checkpoint is serialized along
:with everything else.  So, when I go to resume, I have to be sure
:the file resides at the same path where it was created.
:
:This poses a problem for compressing the file, which I had been
:hoping to do.  Any one know of a way to keep the fd from being
:serialized?  The only way I can think of to get around this is to
:alter elf_getfiles in the kernel to ignore files which can't be
:reloaded.
:
:_why

    Hmm.  I think this would be pretty easy to do, but it is slightly
    more complex then it appears.  But I can solve another little niggling
    problem with the checkpointing code at the same time which is when
    you checkpoint a program which has been checkpoint-restored, it needs
    BOTH checkpoint files to properly restore.  This iterates.  So if you
    checkpoint a program, then restore from the checkpoint, then checkpoint it
    again, then restore from the new checkpoint, and so forth... ALL the
    checkpoint files must exist to properly restore the program.

    I may be able to fix this and fix the issue you brought up quickly.  I am
    going to give it a shot.  The solution is to flag the file that
    represents the checkpoint restore file, and to treat
    checkpoint-file-backed data as anonymous memory when re-checkpointing
    a program to force it to be written out in full (thus removing the
    dependancy on earlier checkpoints).

					-Matt
					Matthew Dillon 
					<dillon@backplane.com>