1,067
edits
Changes
Jump to navigation
Jump to search
Line 1:
Line 1: − * [http://lwn.net/Articles/517079/ v0.2] release 20 Sep 2012+ − * [http://lwn.net/Articles/507796/ v0.1] release 23 Jul 2012 − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + Line 20:
Line 57: − + Line 44:
Line 81: − + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + − * Pavel sent POC in LKML.+ − From: Pavel Emelyanov+ − Subject: [RFC][PATCH 0/7 + tools] Checkpoint/restore mostly in the userspace+ − Date: Fri, 15 Jul 2011 17:45:10 +0400
simplify a notch
Here we list major project milestones.
* Andrew Morton starts to doubt in CRIU [https://lkml.org/lkml/2012/2/14/384 "link"]
== 7 Mar 2016: CRIU 2 ==
With CRIU 2 we
* Switched to monthly releases
* Introduced the devel branch
* Reworked the code structure
== 7 Sep 2015: 1.7, time-driven releases ==
Since 1.7, a new version is released every 3 months, on the first Monday of a season.
== 31 Dec 2013: 1.1 release candidate 1 ==
The biggest change of the 1.1 is going to be
* [[C API|libcriu.so]]
* [[plugins]]
In order to let people try the API and be able to change it if needed, we release the -rc1.
== 25 Nov 2013: Version 1.0 release ==
Some time before this CRIU has come to a state of all the kernel support it needed hit the upstream kernel (3.11). Then the v0.7 was released and the team concentrated on the tool itself. Then there was v0.8 with RPC service, a couple of other new features and a lot of bugfixes. At some point the team has mostly developed the next chunk of changes that was planned and were ready to tag the next version.
It was decided to make it be 1.0.
== "Proof of concept" stage ==
Before 1.0 release CRIU was in the proof-of-concept state. The main goal of the project was defining the kernel API needed to make C/R real.
* 3 Jul 2013: Linus merges memory tracking patches in v3.11. At that point, CRIU becomes as functional as OpenVZ checkpoint-restore kernel code. And CRIU user-space no longer requires custom kernel to work on.
* 1 Jul 2013: [[Download/criu/0.6|V0.6]]
* 30 Apr 2013: [[Download/criu/0.5|V0.5]]
* 12 Apr 2013: Andrew Morton merges "Memory changes tracking" patches. [http://lwn.net/Articles/546966/ These patches] are prerequisite for such things as incremental dumps or iterative migration. We expect this memory tracker to be long-pending task, but things has happened to be simpler and faster than expected.
* 20 Feb 2013: [[Download/crtools/0.4|V0.4]]
* 11 Dec 2012: [[Download/crtools/0.3|V0.3]]
* 20 Sep 2012: [http://lwn.net/Articles/517079/ Checkpoint-restore tool v0.2]
* 23 Jul 2012: [http://lwn.net/Articles/507796/ Checkpoint-restore tool v0.1]
* 14 Feb 2012: Andrew Morton starts to doubt in CRIU. From https://lkml.org/lkml/2012/2/14/384:
Thus far our (my) approach has been to trickle the c/r support code
Thus far our (my) approach has been to trickle the c/r support code
an unsufficiently useful feature) at the end of the project.
an unsufficiently useful feature) at the end of the project.
* Linus merged a first wave of patches, adding his thoughts about this (commit 0994695)
* 12 Jan 2012: Linus merged a first wave of CRIU patches from Andrew Morton. From commit 0994695, the Andrew's quote :
- checkpoint/restart feature work.
- checkpoint/restart feature work.
be a simple matter to go through and delete all trace of it.
be a simple matter to go through and delete all trace of it.
* Jonathan Corbet wrote the article at lwn.net [http://lwn.net/Articles/452184/ "Checkpoint/restart (mostly) in user space"]
* 30 Nov 2011: CRIU name coined, dot org domain registered.
Domain Name:CRIU.ORG
Created On:30-Nov-2011 12:49:39 UTC
* 20 Jul 2011: Tejun sent the ptrace-parasite example code. See [https://lkml.org/lkml/2011/7/20/138 "EXAMPLE CODE Parasite thread injection using PTRACE_SEIZE and friends"].
* 19 Jul 2011: Jonathan Corbet wrote the article at lwn.net. See [http://lwn.net/Articles/452184/ "Checkpoint/restart (mostly) in user space"].
== 15 Jul 2011: Pavel sent initial RFC and code ==
From http://lwn.net/Articles/451916/:
<pre>
From: Pavel Emelyanov
Subject: [RFC][PATCH 0/7 + tools] Checkpoint/restore mostly in the userspace
Date: Fri, 15 Jul 2011 17:45:10 +0400
Hi guys!
There have already been made many attempts to have the checkpoint/restore functionality
in Linux, but as far as I can see there's still no final solutions that suits most of
the interested people. The main concern about the previous approaches as I see it was
about - all that stuff was supposed to sit in the kernel thus creating various problems.
I'd like to bring this subject back again proposing the way of how to implement c/r
mostly in the userspace with the reasonable help of a kernel.
That said, I propose to start with very basic set of objects to c/r that can work with
* x86_64 tasks (subtree) which includes
- registers
- TLS
- memory of all kinds (file and anon both shared and private)
* open regular files
* pipes (with data in it)
Core idea:
The core idea of the restore process is to implement the binary handler that can execve-ute
image files recreating the register and the memory state of a task. Restoring the process
tree and opening files is done completely in the user space, i.e. when restoring the subtree
of processes I first fork all the tasks in respective order, then open required files and
then call execve() to restore registers and memory.
The checkpointing process is quite simple - all we need about processes can be read from /proc
except for several things - registers and private memory. In current implementation to get
them I introduce the /proc/<pid>/dump file which produces the file that can be executed by the
described above binfmt. Additionally I introduce the /proc/<pid>/mfd/ dir with info about
mappings. It is populated with symbolc links with names equal to vma->vm_start and pointing to
mapped files (including anon shared which are tmpfs ones). Thus we can open some task's
/proc/<pid>/mfd/<address> link and find out the mapped file inode (to check for sharing) and
if required map one and read the contents of anon shared memory.
Other minor stuff is in patches and mostly tools. The set is for linux-2.6.39. The current
implementation is not yet well tested and has many other defects, but demonstrates the idea.
What do you think? Does the support from kernel of the proposed type suit us?
Thanks,
Pavel
</pre>