Currently we're using predefined format for master/slave pty peers:
masters are always /dev/ptmx, while slaves are /dev/pts/$index,
where $index is the peer number.
While fitting most of distros this is not always correct and slave peers
might be mounted to an arbitrary place, so that we need to somehow
carry paths with ourself in image.
Instead of bloating current tty image lets use regular file engine instead
and on checkpoint stage save a path to the link in regfiles set, then on
restore simply fetch it from the image.
Such approach will help in future when we need to support multiple
instances of devpts filesystem.
To support backward compatibility with images where no regfile
records are present we generate new one on the fly in
pty_alloc_reg() helper.
Because of the need to restore dead slave peers and restore of
the controlling terminal we need to generate that named "fake
inverted" pty_alloc_fake_reg() helper: in particular if
we need to open dead slave peer we generate fake master peer,
open it and the close out. Almost the same situation in
restoring contolling terminal -- we get master peer, generate
appropriate fake slave object, open it, manipulate, then
close it out and free.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Acked-by: Tycho Andersen <tycho.andersen@canonical.com>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
criu
====
An utility to checkpoint/restore tasks. Using this tool, you can
freeze a running application (or part of it) and checkpoint it to
a hard drive as a collection of files. You can then use the files
to restore and run the application from the point it was frozen
at. The distinctive feature of the CRIU project is that it is
mainly implemented in user space.
The project home is at http://criu.org
Pages worth starting with are
* Kernel configuration, compilation, etc: http://criu.org/Installation
* A simple example of usage: http://criu.org/Simple_loop
* More sophisticated example with graphical app: http://criu.org/VNC
caa64d974d