further thoughts on checkpoint/restart

[Kip Macy <kmacy@xxxxxxxxxxx>]

>     In otherwords, the idea behind the checkpointing is to try to cover as
>     many situations as possible, but one still needs to be running reasonably
>     well behaved code for it to work.  We might, one day, provide
>     persistent filesystem functionality (say, by bumping the inode's link
>     count) but it would be unreasonable to try to do something that
>     sophisticated in step #1.
>

Matt - Is it possible to re-open a file over NFS given a dev_t and inode?
My understanding is that it isn't. If we need the absolute path, we will
need to add a hook to open() to record it. This quickly butts its head up
against resource limits.

I don't know of *any* way of tracking device state in a general way,
for example if I have an OS simulator that is simulating an ethernet
card via BPF, I would have to add code specifically for saving and
restoring BPF state. TCP connections are another non-starter. I've come to
the conclusion that the user application will have to take responsibility
for restoring state for anything other than registers, mappings, and
signal dispositions. A comparatively non-intrusive way to do this is to
allow it to register a thaw hook. This would be much like a signal handler
or atexit, but it would be called immediately before returning from thaw.
Under this setup, the application won't have to call freeze or thaw
(suspend/restart), but it will have to register a hook for restoring any
additional state. Does anyone have a better solution?

Matt - I realized that to support rfork-threads, all I need to do is write
an additional prstatus note out for each additional thread, everything
else remains the same. All in all it should only add 10-20 lines to
elf_coredump. This would have the added benefit of allowing gdb to debug
rfork-threaded applications. Am I correct in assuming that if I write this
you or Dave will commit my changes to elf_coredump in imgact_elf.c?


				-Kip