X applications

From CRIU
Revision as of 08:38, 9 April 2019 by Radostin (talk | contribs) (Add links to documentation)
(diff) ← Older revision | Latest revision (diff) | Newer revision → (diff)
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


Problem

Doing C/R of an X-application is not currently supported due to a simple fact -- all X-apps hold connections to X-server and, sometimes, have a video-card-related device opened as a file or even mapped as a virtual memory region.

Connection to X-server

X-server connection is a typical TCP (or Unix) socket that CRIU can handle by itself. And, in theory, we could dump an X-application and restore it on the same machine, making the X-server "think" that nothing has changed. Unfortunately, this is not what "checkpoint and restore an X-app" is expected to be. The expectation is when after checkpoint the app window(s) disappear from the screen and after restore they pop-up on it again. In order to achieve this CRIU needs to "talk" to the X-server no both checkpoint and restore sides.

On the checkpoint node we need to get the list of associated with the application resources that X-server maintains in memory to serve the application X-needs.

On the restore node we need to put the resources in question back to the X-server to make the app window(s) pop-up on the screen again (in simple words).

Both tasks require some (maybe deep) knowledge/understanding of the X-server and X-protocol.

Video card device

CRIU can handle some devices, in particular ttys and virtual /dev/null|zero|etc. ones. For a "more real" device the situation is close to what has just been described -- a device is likely to have some state regarding the application referring it via file descriptor or a memory mapping. This state also has to be handled somehow.

See also

Xorg Documentation

Xlib - C Language X Interface