You can do checkpoint/restart in userspace, now if you want to. That
requires the application to know about it.
I thought we were talking about a checkpoint/restart with minimal
kernel support that would allow a non-aware program to be
checkpointed/restarted.
Something like
killall -99 xemacs
would generate a large CORE file, which would have the neccesary info
to restart the program without any support from the "child" process.
Next a program "restart" would be used to restart that core...
restart -fd_is_current_tty 3 ./core
Which tells the restart program that fd number 3 need not be
reconnected to the old filesystem object, but to the current tty.
The "restart" program already has a lot of tools that can empower
it to do its work:
open filedescriptors
exec binary
ptrace: set memory image to what it was before.
ptrace: set IP to where it was.
The only thing that needs to be done is to modify the coredump format
to give enough info to the restart program.
I find it highly acceptable if at first some stuff is "just too hard".
For example, an internet socket is a problem. How do you restart that?
The "new" core file format should define how this will be handled,
("Warning: Unknown tag 0x53, whatever this means, this program cannot
handle this feature. Skipping tag.").
Regards,
Roger.
-- If it's there and you can see it, it's REAL |___R.E.Wolff@BitWizard.nl | If it's there and you can't see it, it's TRANSPARENT | Tel: +31-15-2137555 | If it's not there and you can see it, it's VIRTUAL |__FAX:_+31-15-2138217 | If it's not there and you can't see it, it's GONE! -- Roy Wilks, 1983 |_____|- To unsubscribe from this list: send the line "unsubscribe linux-kernel" in the body of a message to majordomo@vger.rutgers.edu