mnt: Add simfs entry to a list of supported fs

simfs is used in OpenVZ containers, so lets understand it
and don't fail on its meeting.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: Introduce cpt2 sourceless directory

There are no real source code yet, only docs
and a general Makefile. So nothing will be
yet build.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 - Add bare entry routine

Introduce main() routine which does nothing but
reports "usage message" if no command line option
provided.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add a bunch of headers needed

This commit adds a couple of headers which will be
needed for cpt2 tool. In particular

 - bug.h -- for BUG/BUG_ON helpers
 - err.h -- for pointer/error code casting
 - hash.h/hashtable.h -- helpers for efficient hashing
 - list.h -- list/hash-list helpers
 - magicfs.h -- for superblock magic numbers
 - memory.h -- for xalloc/free helpers
 - types.h -- general types for cpt2 tool

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Introduce exportfs helpers

In criu we encode file descriptors for fsnotify
as file handlers so this helpers will be needed
to generate them.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Introduce io operations

These are general io operations which will
be used all over the tool code (note if needed
we can easily switch read/write system calls
with mmap'ed io if needed. For now I left it
in regular read/write operations until all things
are stabilized).

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Itroduce fdset operations

We will need to carry a set of opened file
descriptors. This commit provides convenient
helpers to operate with them.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add structures to parse OpenVZ image format

The cpt-image.h is taken from OpenVZ source code and
adopted for cpt2 needs.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Introduce program context and image helpers

Program context, represented by context_t type, stands to
carry critical parameters needed for sharing between code
modules. These are dumpfile and output directory descriptors,
dumpfile statistics, headers, dumpfile sections offsets
and file set for global criu files.

Because context uses global criu file set, we introduce criu
image helpers, which describe criu file templates and helpers
to work with them.

Image helpers and templates are taken from crtools code and
adopted for cpt2 needs, still it might be worth to split
crtools' image helpers in somewhat more abstract code which
would allow to re-use it in cpt2. For a while there is some
code duplication.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Introduce protobuf helpers

This patch introduces protobuf helpers which are
taken from crtools code and adopted for cpt2. It
would be great one day to have these helpers as
a library exported from crtools. For a while it's
some code duplication.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Introduce "object" abstraction

Objects are aimed to carry real data read from dump files.
Usually the data read is placed after the __payload pointer

[ though the object may carry another structures like a
  container and in this case __payload is followed by
  embedded data while image data addressed by o_image
  member, will be explained later ].

For fast lookup of objects by their position read from dumpfile
there is 16K object chain-hash. 16K should be enough for now,
still if one day we see serious contention (which I quite doubt
in) the hash size can be easily increased by tuning OBJS_HASH_BITS
value.

Because of dumpfile format specifics objects types up to CPT_OBJ_MAX
are linked to per-type lists, allowing a caller to walk over all
of them via regular list helpers code. If possible try to not use
@o_list member for anything else, until really needed.

When read, each object is assigned with unique 32 bit id.

Because objects on its own are not that usefull, the general
idea of their presense is to carry other structures. For this
sake a number of macros provided in obj.h header file.

Lets consider we need to work with the following structure

struct some_struct {
	struct list_head	list;
	struct cpt_image	image;
} *entry;

where @list is a member we use for own linking (outside of objects'
subsystem) and @image is some member from cpt-image.h file and
represent a record in dumpfile.

First we allocate structure as

	entry = obj_alloc_to(struct some_struct, image);

then we may read data to @image member with help of
read_obj_cpt() macro.

Once object no longer needed, we can call to obj_free_to(entry)
and get it destroyed.

For convenience helpers are postfixed with _to and _of names,
_to is used when operate with pointer to a compound object, and
_of operate with pointer to obj_t.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Start reading dumpfile

This commit introduces dumpfile reading routines.
The main one is read_dumpfile() which is supposed
to call all readers from other subsystems.

Once read complete (and conversion is done, which is
addressed in further patches) the read_fini() should
be called to free all resource allocated.

At moment we only read dumpfile headers and parse
sections, nothing else.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Read files, fds, inodes, fs related info

In this patch we put the ground for reading files,
opened file descriptors, inodes and fs related info
(current working directory and root).

The relation between structures is the following

 - fs_struct keeps info about root and cwd directory
   which is associated with a task

 - files_struct keeps a list of opened file descriptors
   which is associated with a task as well

 - fd_struct represents opened file descriptor itself
   and it's associated with files_struct

 - file_struct represents data associated with a file,
   among other things we have @dumped entry here thus
   once file is converted and written to criu image
   file the @dumped set to true and we never write it
   again (in criu this work is indirectly done for us
   by kcmp call -- we never generate "new" files if one
   has been seen already)

There is no "write to criu image" action yet, just reading
for simplicity.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add signal handlers reading scaffolds

We just read signal handlers from image, and that's all.
The only thing which need to be kept in mind is that
OpenVZ image do skip signal handlers with default actions,
while in criu we do dump all signals.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Read inotify entries

As subject implies -- just read inotify entries.
Note the openvz image has queued events dump but
we don't support them in criu, so we just ignore it.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Read vfs mount points

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Read mm/vma data from dumpfile

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add FPU header to carry xsave frames

We will need it for FPU state conversion. It's copied
from crtools code, I need to start using crtools' one
but it requires some makefile tuning, so just copied
for a while.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add reading of tasks

Here we read tasks from image and build
parent -> child relationship, as well as
figuring out how many threads are present.

(this information present differently in
 openvz image thus we have to use own pids
 hash for fast lookup)

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>
tools: cpt2 -- Add reading of sockets

Sockets can be found from files as a reverse
chain, so we need own hash here.

Signed-off-by: Cyrill Gorcunov <gorcunov@openvz.org>