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>
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>
This is less useful than fixing typos in output messages, but anyway.
Signed-off-by: Kir Kolyshkin <kir@openvz.org>
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>
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>
This patch switches reg_file_entry structure with RegFileEntry
protobuf entry. Note that there a few nits remains
- old fown_t structure doesn't scale well with FownEntry from
RegFileEntry, so to not mess with rest of crtools code
I've added a couple of opencoded copy operands, will clean
this aspect up once rest of code is converted
- the "show" procedure doesn't print fown for same reason
v2:
- rename fown_t to fown_entry in .proto
v3:
- don't print nil symbol on show
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
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>
The ret var is set to -1 at the beginning and the very first loop
will break and report it to the caller thus stopping the restore :(
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Don't push open cb onto reg_file_into, pass it into regfiles engine
as an argument.
Note: I haven't merged the fifo zdtms yet, thus this patch is untested.
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
Tested-by: Cyrill Gorcunov <gorcunov@openvz.org>
Checkpoint and restore of fifo is similar to
pipes c/r except the pipe end-points are named
file.
Because the fifo has a name we use regular files
facility for fifo path c/r.
Still there is a trick used to "open" fifo:
the opening procedure migh sleep if a fifo's peer
is not yet opened, so before doing a real open
we yield a fake open procedure (with O_RDWR flag)
which prevents us from sleeping even if peer
is not yet ready. Also we need writable fifo
end to restore data queued.
v2:
- add open/priv members to reg_file_info
- make open_fifo_fd to use open_fe_fd
- comment on pipe_id
- make sure the fifo data is not restored twice
v3:
- drop useless fixme comment and add sane one
v4:
- Use restore_data flag to escape data restore duplication
- Use S_ISREG for file contents copying
Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
Signed-off-by: Pavel Emelyanov <xemul@parallels.com>
