Difference between revisions of "CR tools"
| Line 11: | Line 11: | ||
== Basic design == | == Basic design == | ||
| + | === Checkpoint === | ||
| − | + | The checkpoint procedure relies heavily on '''/proc''' file system (it's a general place where crtools takes all the information it needs). | |
| + | |||
| + | This includes: | ||
| + | * Files descriptors information (via '''/proc/$pid/fd''' and '''/proc/$pid/fdinfo''') | ||
| + | * Pipes parameters | ||
| + | * Memory maps (via '''/proc/$pid/maps''') | ||
| − | + | Though not all parameters can be observed this way, say the current '''brk()''' value of a process is not exported at all. | |
Revision as of 21:04, 14 October 2011
What CRtools is
CRtools is an utility to checkpoint/restore process tree. Unlike checkpoint/restore implemented completely in kernel space, it tries to achieve the same target mostly in user space.
Agenda
- Basic design (checkpoint == proc + SEIZE, restore == syscalls + execve)
- What's required from kernel
Basic design
Checkpoint
The checkpoint procedure relies heavily on /proc file system (it's a general place where crtools takes all the information it needs).
This includes:
- Files descriptors information (via /proc/$pid/fd and /proc/$pid/fdinfo)
- Pipes parameters
- Memory maps (via /proc/$pid/maps)
Though not all parameters can be observed this way, say the current brk() value of a process is not exported at all.
