Hi!
One reason is that I suspect that stops us from being able to send thatYeah, it does seem kinda backwards. But, instead of even having toI have to wonder if this is just a symptom of us trying to do this theMaybe you can invert the logic and let the new syscalls create a file
wrong way. We're trying to talk the kernel into writing internal gunk
into a FD. You're right, it is like a splice where one end of the pipe
is in the kernel.
Any thoughts on a better way to do this?
descriptor, and then have user space read or splice the checkpoint
data from it, and restore it by writing to the file descriptor.
It's probably easy to do using anon_inode_getfd() and would solve this
problem, but at the same time make checkpointing the current thread
hard if not impossible.
worry about the anon_inode stuff, why don't we just put it in a fs like
everything else? checkpointfs!
data straight to a pipe to compress and/or send on the network, without
hitting local disk. Though if the checkpointfs was ram-based maybe not?
As Oren has pointed out before, passing in an fd means we can pass a
socket into the syscall.
If you do pass a socket, will it handle blocking correctly? Getting
deadlocked task would be bad. What happens if I try to snapshot into
/proc/self/fd/0 ? Or maybe restore from /proc/cmdline?