Difference between revisions of "X applications"
m (Add links to documentation) |
|||
| (One intermediate revision by the same user not shown) | |||
| Line 1: | Line 1: | ||
[[Category:Plans]] | [[Category:Plans]] | ||
| − | |||
== Problem == | == Problem == | ||
| − | Doing C/R of an X-application is | + | 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 == | == Connection to X-server == | ||
| − | + | X-server connection is a typical 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 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 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 | + | 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 | + | Both tasks require some (maybe deep) knowledge/understanding of the X-server and X-protocol. |
== Video card device == | == 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 == | ||
| + | [https://www.x.org/wiki/Documentation/ Xorg Documentation] | ||
| + | |||
| + | [https://www.x.org/releases/X11R7.7/doc/libX11/libX11/libX11.html Xlib - C Language X Interface] | ||
Latest revision as of 08:38, 9 April 2019
Problem[edit]
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[edit]
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[edit]
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.