Todo - Revision history

Efiop: remove @efiop's asignees

2021-12-06T08:33:14Z

remove @efiop's asignees

Dsafonov: vdso remapping fixed for arm64/arm32/ppc64/ia32 running on x86_64, s390 doesn't need this - looks like, each supported architecture is covered; for any new architecture there is an easy way now in kernel to add .mremap() to special_mapping_ops

2018-04-04T14:36:14Z

vdso remapping fixed for arm64/arm32/ppc64/ia32 running on x86_64, s390 doesn't need this - looks like, each supported architecture is covered; for any new architecture there is an easy way now in kernel to add .mremap() to special_mapping_ops

Rppt at 07:37, 28 September 2017

2017-09-28T07:37:08Z

Efiop: rm patch tester task

2016-05-06T19:15:40Z

rm patch tester task

Sergey Bronnikov: make note more visible

2016-02-20T09:01:19Z

make note more visible

Sergey Bronnikov: Update link to GIT repo

2016-02-20T08:57:17Z

Update link to GIT repo

Xemul at 20:49, 10 December 2015

2015-12-10T20:49:58Z

Finist at 14:39, 30 October 2015

2015-10-30T14:39:56Z

Efiop: checkpoint tokens without recompiling

2015-09-28T11:57:15Z

checkpoint tokens without recompiling

Xemul at 16:02, 24 September 2015

2015-09-24T16:02:03Z

@@ Line 35: / Line 35: @@
 | crtools || [[Integration]] with other projects || hard || - || CRIU is not working great by itself. There's alway some specific about what user wants to dump. Integrating CRIU with other projects will make CRIU work at its best.
 |-
-| crtools || Restore tasks into fresh new pid namespace || easy || Kuprieiev Ruslan || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.
+| crtools || Restore tasks into fresh new pid namespace || easy || - || When we dumped processes, it can be hard to restore it back, if they didn't live in a pid namespace, due to PIDs conflict. It would be nice to have the ability to ask CRIU to create the pid namespace for those guys and restore them there. A thing to worry about is this new namespace's init task.
 |-
 | crtools || Rollback tree state || medium || - || When we checkpointed process tree with -R option (let them run after checkpoint) we might want to return the tasks into checkpointed state on the same machine. Currently this can only be done by killing the processes and restoring them from scratch. If we could ask CRIU to restore the images ''into'' the ready processes that could speed things up, especially if carefully caring about [[memory changes tracking]].
@@ Line 67: / Line 67: @@
 | crtools || Restore arbitrary process tree || hard ||  - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/session02.c session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).
 |-
-| crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.
+| crtools || C/R [[X applications]] || hard || - || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.
 |-
 | crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/checkpoint-restore/criu/blob/master/criu/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.

@@ Line 72: / Line 72: @@
 |-
 | crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.
 |-
 | tests || Run many/all tests in "container" || medium || - || Currently we run zdtm tests one-by-one. It would be nice to run the all in one pseudo-container and C/R them as one big subtree.

@@ Line 1: / Line 1: @@
-{{note|This list is being transformed into the [https://github.com/xemul/criu/issues github issues]}}
+{{note|This list is being transformed into the [https://github.com/checkpoint-restore/criu/issues github issues]}}
 {| class="wikitable sortable"
@@ Line 65: / Line 65: @@
 | kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly — dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.
 |-
-| crtools || Restore arbitrary process tree || hard ||  - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [https://github.com/xemul/criu/blob/master/test/zdtm/live/static/session02.c session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).
+| crtools || Restore arbitrary process tree || hard ||  - || Need to restore any process tree, which could be created with help PR_SET_CHILD_SUBREAPER and CLONE_PARENT. Processes can share other resources [http://man7.org/linux/man-pages/man2/clone2.2.html clone(2)]. Look at [https://github.com/checkpoint-restore/criu/blob/master/test/zdtm/static/session02.c session02]. The task of resolving the given images into operations we might need to perform seem to be NP (not proven though).
 |-
 | crtools || C/R [[X applications]] || hard || Ruslan Kuprieiev || Dump/restore of graphical applications (see about [[integration]]). In case of X app part of its state is stored into the X-server. Need the way to fetch this state during dump and put this state back into the server on restore. Requires fixing the X-server software too.
 |-
-| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/xemul/criu/blob/master/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.
+| crtools || More detailed RPC fail codes || easy || - || Currently only 3 typical errors are reported(see [https://github.com/checkpoint-restore/criu/blob/master/criu/include/cr-errno.h#L8 include/cr-errno.h]). Need to extend this set as currently it's hard to understand what has happened w/o analysing CRIU log files.
 |-
 | crtools || Make CRIU work on AArch32 with CONFIG_KUSER_HELPERS=n || medium || cov || CRIU currently fails on AArch32 kernels built with CONFIG_KUSER_HELPERS=n.

@@ Line 78: / Line 78: @@
 |-
 | tests || [[Fuzz testing|Trinity-like (fuzz) testing]] || hard || - || The existing suite is 99% functionality testing. Need more sophisticated testing -- take a process that has done a random set of actions, C/R one, check that all is OK. The latter is the most complicated thing.
 |-
 | crtools || Set checkpoint tokens without recompiling || medium || - || Sometimes you need to call checkpoint in some particular point of the code. The way to do it now is to recompile app with criu_dump() call where needed. But it is quite a bummer to recompile, repackage and redistribute an app you want to c/r. It would be great if one could set a token in app source and then let criu find that point in running task and take a snapshot. The best way to do it might be in libcriu.

← Older revision		Revision as of 09:01, 20 February 2016
Line 1:		Line 1:
−	This list is being transformed into the ~~github issues @~~ https://github.com/xemul/criu/issues	+	{{note\|This list is being transformed into the [https://github.com/xemul/criu/issues github issues]}}

	{\| class="wikitable sortable"		{\| class="wikitable sortable"

@@ Line 77: / Line 77: @@
 | tests || Run many/all tests in "container" || medium || - || Currently we run zdtm tests one-by-one. It would be nice to run the all in one pseudo-container and C/R them as one big subtree.
 |-
-| tests || Trinity-like (fuzz) testing || hard || - || The existing suite is 99% functionality testing. Need more sophisticated testing -- take a process that has done a random set of actions, C/R one, check that all is OK. The latter is the most complicated thing.
+| tests || [[Fuzz testing|Trinity-like (fuzz) testing]] || hard || - || The existing suite is 99% functionality testing. Need more sophisticated testing -- take a process that has done a random set of actions, C/R one, check that all is OK. The latter is the most complicated thing.
 |-
 | tests/infrastructure || Run tests on patches sent to the mailing lists || medium || Ruslan Kuprieiev || It's quite typical that a set sent to the mailing list fails some tests. Need a robot that would monitor the list, check the patches and send the result back.

@@ Line 82: / Line 82: @@
 |-
 | crtools || Set checkpoint tokens without recompiling || medium || - || Sometimes you need to call checkpoint in some particular point of the code. The way to do it now is to recompile app with criu_dump() call where needed. But it is quite a bummer to recompile, repackage and redistribute an app you want to c/r. It would be great if one could set a token in app source and then let criu find that point in running task and take a snapshot. The best way to do it might be in libcriu.
 |}
 [[Category:Development]]
 [[Category:Plans]]

@@ Line 50: / Line 50: @@
 |-
 | crtools || Page transfer filters || medium || - || The page-xfer engine just splices the pages from stealing pipes into socket. Packing or encrypting the data would be nice. Maybe it's purely for [[P.Haul]]?
 |-
 | crtools || TCP socket migration with changed IP || medium || - ||  It might make sense to migrate a tcp connection on a box with changed IP address _if_ both boxes are NAT-ed to the destination. We will then have to go to NAT box and fix the conntracks in that case and use CRIT images modifucation facilities.
@@ Line 64: / Line 62: @@
 |-
 | kernel/crtools || [[TCP repair TODO|TCP repair fixes]] || hard || - || We can dump and restore live [[TCP connection]]. There are some issues with it, that should be fixed.
 |-
 | kernel || [[Seamless kernel upgrade]] || hard || xemul || Briefly — dump tasks (into memory), change the kernel w/ kexec, then restore tasks back. From the tasks and remote client perspective tasks has just stopped and then resumed on the newer kernel. Can be a good complement to the classic live-patching technology.