X applications

From CRIU
Revision as of 14:58, 25 March 2019 by Xemul (talk | contribs)
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 now impossible due to a simple fact -- all X-apps hold a connections to X-server and, sometimes, have a video-card-related device opened as a file or even mapped as a virtual memory region. Both have problems checkpointning and restoring.

Connection to X-server

A connection to the X-server is typically a 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 box 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. Do to _this_ we need to talk to X-server no both sides -- checkpoint node and restore one.

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 pop-up on the screen again (in simple words).

Both tasks require some (maybe deep) knowledge about the X-server and X-protocol we do not currently have in our team.

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 _may_ have some state regarding the application referring it via file descriptor or a memory mapping. This state also has to be handled somehow.