crtools.h is too heavy to be included in many sources
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There's ... a number of places where we want to do something
with /proc/self/fd/%d path. Each time we guess buffer size
that is enough for this. Make standard constant for this and
save some space on stack and drop args for some functions.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
These contain linkage between number, data type and routines
for pb messages we write/read to/from image files. Most of them
have simple number-type-routines mapping, so introduce a generating
script for that.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Since *all* of them just call do_dump_gen_file with proper ops,
just call one directly. Compacts the code.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The system call open can add O_LARGEFILE.
A point is reopend for unsharing a file descriptor. So here are two
types of points. One is returned by pipe() and all other ones are
got via opening /proc/PID/fd.
Currently I know only one difference between these types, it's
O_LARGEFILE.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Tested-by: Alexander Kartashov <alekskartashov@parallels.com
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This mode was introduced less than year ago:
commit 9883035ae7edef3ec62ad215611cb8e17d6a1a5d
Author: Linus Torvalds <torvalds@linux-foundation.org>
Date: Sun Apr 29 13:12:42 2012 -0700
pipes: add a "packetized pipe" mode for writing
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It contains info about the pipe itself, not jut one of its
ends. Thus if we want to add more (e.g. -- its size) we'll
have to put it there and thus have it always present.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Currently fdinfo dumps for each task, so CR_FD_FDINFO is in cr_fdset.
A few tasks can share one fd table and the set of descriptors will be
dumped once and a image name will contain files_id instead of pid.
In this case CR_FD_FDINFO will go away from cr_fdset.
Signed-off-by: Andrey Vagin <avagin@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
There are places when we have to select which fd to ->open
and which to ->receive. To avoid deadlocks we sort them in
an ascending order on { pid, fd } pair.
Make this idea more formal by introducing an explicit function
doing this check and call it where appropriate (pipe.c master
selection is also simplified to fit new ... API).
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It doesn't makemuch sense in pulling this further. The generic genid generation seems to
be enough for eny file type.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
On restore we typically read an image and put the entries into
some hash/list/whatever to work on them later. It's handy to have
a generic routine for doing so.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The pb_read thing is no longer a macros. This will allow to
factor out objects collecting on restore.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This types specifies a strict set of what is hidden behind
the fd. Thus these numbers should be in the description of
the fdinfo message.
Plus protobuf makes shure nothing else will be there.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We are ready to use FownEntry everywhere,
so drop fown_t type and clean up source code.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Note, at moment we don't use "data" from proto declaration,
it's reserved to implement later (simply because it's easier
to use current code for a while).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
A short story -- there were a long conversation on which format should
be used to keep checkpointed data on disk image. We ended up in using
Google's Protocol Buffers (see https://developers.google.com/protocol-buffers/
for detailed description). Thus image entries should be convered to PB.
This patch converts fdinfo_entry to PB "message fdinfo_entry".
Build note: one should have protobuf and protobuf-c installed to be able
to build crtools.
- http://code.google.com/p/protobuf/
- http://code.google.com/p/protobuf-c/
Inspired-by: Pavel Emelianov <xemul@parallels.com>
Inspired-by: Kinsbursky Stanislav <skinsbursky@openvz.org>
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This serves two things -- kills annoying data offset management
which makes protobuf switch too ugly. And removes the need to
seek the pipe data image, which in turn is the prerequisity for
streaming migration.
Memory usage is still optimal, since we still use splice on dump
path and on restore stage we F_GIFT pipe buffers to the kernel.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To open /proc/self/fd/%d PATH_MAX array is too long :) We can use shorter.
Plus fix the snprintf size argument.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Make it in two stages.
First -- collect pipe data into hash without checking for pipe/fifo existance.
Next -- when pipe/fifo gets restored walk the hash and search where the pipe data
is.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
The existing code checks for ID to be already dumped. But pipe and fifo may have the same ID
since they reside on different filesystems.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
This routine checks for pipe data being dumped based on pipe ID, but the arg in questoin
is the pipe's end ID which makes code reading confusing.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
We will need to use pointer here (to PB object) anyway
so better to make it in a separate patch for bisectability sake.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
To reuse with fifo data restore.
v2:
- use image type in functions arguments instead of forcing
calling side to provide file descriptor
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's only required for making pipe_id, but making it is better to
be done in place and using the st_ino only.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Otherwise its value might be taken from heap (it's xmalloc'ed).
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
- align members
- comment with empty line
No func changes.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
It's static function near the file_desc_ops,
no need for a long name.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Checkpoint and restore do use fdtype_ops
and file_desc_ops intensively so reorder
pipes functions, this allow us to make
them static and drop additional declarations.
No func changes.
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
