DragonFly kernel List (threaded) for 2003-09
further thoughts on checkpoint/restart
> 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?