X applications - Revision history

Radostin: Add links to documentation

2019-04-09T08:38:53Z

Add links to documentation

Radostin at 20:58, 2 April 2019

2019-04-02T20:58:20Z

Xemul at 14:58, 25 March 2019

2019-03-25T14:58:55Z

Xemul: empty

2015-02-20T17:14:53Z

empty

Xemul: Created page with "Category:Plans"

2015-02-20T17:09:25Z

Created page with "Category:Plans"

New page

[[Category:Plans]]

@@ Line 1: / Line 1: @@
 [[Category:Plans]]
 == Problem ==
@@ Line 19: / Line 18: @@
 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.

@@ Line 4: / Line 4: @@
 == 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.
+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 ==
-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.
+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 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).
+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 about the X-server and X-protocol we do not currently have in our team.
+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 _may_ have some state regarding the application referring it via file descriptor or a memory mapping. This state also has to be handled somehow.
+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.

← Older revision		Revision as of 14:58, 25 March 2019
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.

← Older revision		Revision as of 17:14, 20 February 2015
Line 1:		Line 1:
	[[Category:Plans]]		[[Category:Plans]]
		+	[[Category:Empty articles]]