Restorer v2 - Revision history

Alak: Grammar fix.

2020-07-23T16:38:31Z

Grammar fix.

2016-09-12T12:13:45Z

Process tree, sessions and groups

2016-09-12T10:41:14Z

Process tree, sessions and groups

2016-09-12T10:38:36Z

Examples

2016-09-08T22:33:49Z

Process tree, sessions and groups

2016-09-08T22:33:34Z

Process tree, sessions and groups

2016-09-08T22:26:49Z

2015-09-10T18:49:45Z

2015-09-10T18:49:14Z

Concept

2015-09-10T18:48:29Z

Concept

← Older revision		Revision as of 16:38, 23 July 2020
Line 1:		Line 1:
−	The current way of restoring from images is quite straightforward -- we just fork the necessary amount of tasks, then each of them starts "dressing" itself based on the data from image files. Sometimes shared resources appear, e.g. files inherited or sessions inherited on fork, or CLONE_XXX objects. With these we write code, that handles only this type of resources -- files a sent to co-owners via unix sockets, CLONE_XXX stuff is pre-created on fork stage. Sometimes more interesting dependencies arise, for example -- [[invisible files]]. These are also special-cared.	+	The current way of restoring from images is quite straightforward -- we just fork the necessary amount of tasks, then each of them starts "dressing" itself based on the data from image files. Sometimes shared resources appear, e.g. files inherited or sessions inherited on fork, or CLONE_XXX objects. With these we write code, that handles only this type of resources -- files are sent to co-owners via unix sockets, CLONE_XXX stuff is pre-created on fork stage. Sometimes more interesting dependencies arise, for example -- [[invisible files]]. These are also special-cared.

	All this is not nice. We believe, that the restoring process can (and should) look better. Like this.		All this is not nice. We believe, that the restoring process can (and should) look better. Like this.

@@ Line 38: / Line 38: @@
 SETSID:     {S(.)(.)(.*)}                -> {S\1S\3}           // S becomes a new session leader
 SETPGID(0): {P(.)(.)(.*)}                -> {PP\2\3}           // P becomes a new group leader
-SETPGID(G): {GGS(.*)}(.*){P(.)S(.*)}     -> {GGS\1}\2{PGS\4}   // P joins group of alive G
+SETPGID(G): {GGS(.*)}(.*){P(.)S(.*)}     -> {GGS\1}\2{PGS\4}
 </pre>
 [[Category: Plans]]
 [[Category: Thinkers]]

@@ Line 38: / Line 38: @@
 SETSID:     {S(.)(.)(.*)}                -> {S\1S\3}           // S becomes a new session leader
 SETPGID(0): {P(.)(.)(.*)}                -> {PP\2\3}           // P becomes a new group leader
-SETPGID(G): {GG(.)(.*)}(.*){P(.)(.)(.*)} -> {GG\1\2}\3{PG\4\6} // P joins session of alive G
+SETPGID(G): {GGS(.*)}(.*){P(.)S(.*)}     -> {GGS\1}\2{PGS\4}   // P joins group of alive G
 </pre>
 [[Category: Plans]]
 [[Category: Thinkers]]

@@ Line 28: / Line 28: @@
 <pre>
-{111\nil}
+{111}
 </pre>
@@ Line 36: / Line 36: @@
 FORK:       {T(..)(.*)}                  -> {T\1N\2}|{N\1}     // T forks N
 EXIT:       {I(..)(.*)}(.*){X(..)(.*)}   -> {I\1\2\5}\3        // X exits and all its kids are reparented to I (init)
-SETSID:     {S(.)(.*)}                   -> {SS\1}             // S becomes a new session leader
+SETSID:     {S(.)(.)(.*)}                -> {S\1S\3}           // S becomes a new session leader
-SETPGID(0): {P(.)(.)(.*)}                -> {P\1P\3}           // P becomes a new group leader
+SETPGID(0): {P(.)(.)(.*)}                -> {PP\2\3}           // P becomes a new group leader
-SETPGID(G): {G(.)G(.*)}(.*){P(.)(.)(.*)} -> {G\1G\2}\3{P\4G\6} // P joins session of alive G
+SETPGID(G): {GG(.)(.*)}(.*){P(.)(.)(.*)} -> {GG\1\2}\3{PG\4\6} // P joins session of alive G
 </pre>
 [[Category: Plans]]
 [[Category: Thinkers]]

@@ Line 28: / Line 28: @@
 <pre>
-{111}
+{111\nil}
 </pre>

← Older revision		Revision as of 18:49, 10 September 2015
Line 20:		Line 20:
	This task (in its 2nd description) reminds the task of solving the context-sensitive grammar.		This task (in its 2nd description) reminds the task of solving the context-sensitive grammar.
	[[Category: Plans]]		[[Category: Plans]]
		+	[[Category: Thinkers]]

@@ Line 14: / Line 14: @@
 * fork() — <code>({(*),task,[(*)]}) -> \1,{$new,task,([parent=\2,\3])}</code> which means that any task can create a copy of itself having it as parent (link) and the rest of objects shared
-* open() — <code>{(*),task,(*)} -> {-1,task,[file=$new]},{$new,file,[]}</code> which means that any task can create a new object of type file linked to it
+* open() — <code>{(*),task,(*)} -> {\1,task,[file=$new,\2]},{$new,file,[]}</code> which means that any task can create a new object of type file linked to it
 The restoring process then is: given a final graph or string and the set of generating rules find out what sequence of the latter can produce the former.

@@ Line 13: / Line 13: @@
 Another way of describing the thing is -- a string of sequences like <code>{o,t,[l]*}</code> where <code>o</code> is an ID of an object, <code>t</code> is its type, <code>[l]*</code> is an array of links to another objects. The generation rules can look like
-* fork() - <code>({(*),task,[(*)]}) -> \1,{$new,task,([parent=\2,\3])}</code> which means that any task can create a copy of itself having it as parent (link) and the rest of objects shared
+* fork() — <code>({(*),task,[(*)]}) -> \1,{$new,task,([parent=\2,\3])}</code> which means that any task can create a copy of itself having it as parent (link) and the rest of objects shared
-* open() - <code>{(*),task,(*)} -> {-1,task,[file=$new]},{$new,file,[]}</code> which means that any task can create a new object of type file linked to it
+* open() — <code>{(*),task,(*)} -> {-1,task,[file=$new]},{$new,file,[]}</code> which means that any task can create a new object of type file linked to it
 The restoring process then is: given a final graph or string and the set of generating rules find out what sequence of the latter can produce the former.