Difference between revisions of "X applications"
(empty) |
|||
Line 1: | Line 1: | ||
[[Category:Plans]] | [[Category:Plans]] | ||
[[Category:Empty articles]] | [[Category:Empty articles]] | ||
+ | |||
+ | == 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 [[TCP connection|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. |
Revision as of 14:58, 25 March 2019
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.