- 15 Mar, 2017 40 commits
-
-
Kir Kolyshkin authored
The statement like #include <compel/plugins/plugin-std.h> looks a bit tautological. I think the single "plugins" word is enough: #include <compel/plugins/std.h> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
First, for building compel plugins, we already have "-I compel/include/uapi" in ccflags and asflags, so there is no need to add "-iquote include/uapi". Second, let's refer to compel plugin uapi includes in a uniform way, choosing the same way the external code does, i.e. #include <compel/...>. Third, in a few cases simplify #include statements by including compel/plugins/plugin-std.h instead of a number of plugins/std/*.h files. Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This header should have everything we have in std/ Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
* install 'cp' can copy recursively, create directories, and even dereference symlinks. Everything we have in uapi/ is to be installed. NOTE we can't use -r for compel includes, as there is some extra stuff in there we don't want to take with us (in particular, plugins/ and 'compel -> .' symlinks). * uninstall rm -rf everything under compel includedir While at it, fix some minor things here and there. Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
It is not used anywhere, so unless someone has any plans, let's kill it. Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
A slash after a directory was missing in a number of places, that resulted in "make uninstall" leaving a number of files behind. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
GNU make tries to rebuild any makefiles it uses. While in general it's a good idea (and it is used e.g. in autoconf-based builds), in our case it is not necessary, as all the makefiles are static. More to say, as we have a few "match anything" rules for subdirectories, Makefiles in these subdirs are also matching these rules, which leads to excessive (re)building while a particular makefile is needed. Protect such Makefiles with explicit (or pattern) rules, so make knows it should do nothing to rebuild those. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Apparently @true was used as a rule for any target which should have a non-empty rule doing nothing. For this, there's a "<target>: ;" syntax, let's use this and eliminate an unnecessary fork/exec :) Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Mostly this is done in order to not repeat the recursive clean lines twice. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
As all builds are done from top source dir, there is no need to have SRC_DIR. Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Our whole system of Makefiles are integrated from top to bottom, meaning: 1. The paths in sub-makefiles are relative to the top source dir. 2. Sub-makefiles are executed via make $(build)=<SUBDIR> <TARGET> For some reason, makefiles under lib/ are the exclusion. Let's fix it. Side effect: you can now build any individual target under lib/, for example, "make lib/c/libcriu.so" works. [v2: use the .FORCE, thanks to dsafonov@] Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
As compel is an external tool now, let's treat it as such -- remove the hardcoded paths to compel files, they are now provided via compel CLI. Details: 1. The compel std plugin dependency is dropped from the intermediate criu/Makefile. It was there in order to make sure plugin is built before pie, but the top level Makefile and Makefile.compel take care about it. 2. The compel std plugin logic is simplified in criu/pie/Makefile. 3. The compel linker script dependency is kept as-is for now (except the linker script file name no longer appears in the list of objects to link). 4. Linking of compel std plugin is moved to a second linking stage in order to simplify the Makefile. Side note: we can actually avoid running the linker twice! 5. The compel binary dependency is dropped from criu/pie/Makefile as this is already there in top-level Makefile (look for criu-deps). [v2: reworked after dsafonov@ comments; keep most compel deps] Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
To check that jump trampolines to rt-vdso works. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Reduce __export_restore_task(), which is fat and too long, drop needless parameter from vdso_proxify() and drop also that find-tuple logic, which isn't needed really. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
It's always "dumpee" and is used in two pr_err() messages, put it right there. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
We should log whom we're remapping, but ~5 lines upper or so we've unmapped dumpee vdso and vvar. Here we're mremapping runtime host-provided vdso/vvar blobs to the dumpee position. Correct the messages to reflect that we've remapped rt-vdso/vvar, having the same naming as in vdso_do_park(). Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Remove not needed VDSO_SYMBOL_*_NAME defines. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
For 32-bit at this moment there are follwing entries: o __vdso_clock_gettime o __vdso_gettimeofday o __vdso_time o __kernel_vsyscall o __kernel_sigreturn o __kernel_rt_sigreturn So, there isn't __vdso_getcpu(), which is present in 64-bit vDSO, and 64-bit vDSO doesn't have those __kernel_*. This is fine as two vdso blobs with the same not present symbols are considered to be the same in comparison. I didn't introduce ARCH_VDSO_SYMBOLS_32, as it would have different size and that will result in quite painful conversion of struct vdso_symtable (it's fixed size and e.g., inside parasite's parameters) Which is not needed by the described behavior of vdso blobs comparison. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Dmitry Safonov authored
Forward CRIU's log fd into helper, so it can actually print errors. This will help to debug troubles with helper, like #273. Log fd can be safely written to, as it's opened in CRIU with O_APPEND or it's line-buffered (stdout) or not buffered (stderr) stream. Anyway, it's double safe, as there is simple synchronization between helper and CRIU, so only one of them will log at a time. Also expanded the comment about a helper. Acked-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This macro is not in use since mid-2012 (commit 4806e139 "protobuf: Convert vma_entry to PB format v3"), so I guess it is about time to retire it. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Let's rename the printing functions so their names look more like the standard ones. 1. putc/puts with a file descriptor. __std_putc -> std_dputc __std_puts -> std_dputs There are no standard putc/puts that accept fd as an argument, but the libc convention is to use d prefix for such. Therefore: NOTE we keep the order of the arguments intact, to be in line with the rest of the functions. 2. *printf __std_printk -> std_vdprintf __std_printf -> std_dprintf The reason is, these are the names of libc functions with similar functionality/arguments. Cc: Dmitry Safonov <dsafonov@virtuozzo.com> Cc: Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Reviewed-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This function works like printf, and it helps the compiler to know that, so it can check whether arguments fit the format string. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This function works like printf, and it helps the compiler to know that, so it can check whether arguments fit the format string. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
These are part of compel UAPI so should be prefixed with COMPEL_ in order to not pollute the namespace. While at it, move from set of defines to an enum, which looks a bit cleaner. Also, kill LOG_UNDEF as it's not used anywhere. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
Those macros look twice as long as they should be on my 80-columns terminal. As there is nothing here to justify such width, go ahead and remove the extra tabs, keeping the code within 80 cols. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
We support compat mode now (at least partially) so the test should be allowed. Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
To support ia32 compat mode on x86-64 we need to things - extend fpu_state_t type to carry ia32 specifics - fill up additional members in fpu_state_ia32_t type before calling sigreturn (this also requires the uc_mcontext::fpstate won't be aligned on 32 bytes) Because we touches base types in compel the criu has been updated accordingly. Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
In compat mode the fpu frame won't be aligned on 32 bit due to kernel specifics. Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Cyrill Gorcunov authored
It was never functional neither we plan to support native ia32 mode, so drop these incomplete code pieces out. - Presumably we will need TASK_SIZE for compat mode so I provide TASK_SIZE_IA32 for this sake - 32 bit syscalls are remaining for a while Acked-by:
Dmitry Safonov <dsafonov@virtuozzo.com> Acked-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
It's now obsoleted by compel library. Maybe-TODO: Add compel tool exec action? Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Pavel Emelyanov authored
Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
This is the difference between two commits criu-dev/b0f6f293/Unify own memcpy/memset/memcmp master/0367a1fe/Drop prefix from own memcpy/memset/memcmp that makes criu-dev after rebase on master with latter commit be the same as it was with former commit before rebase. Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
First, TASK_* defines provided by compel should be prefixed with COMPEL_. The complication is, same constants are also used by CRIU, some are even writted into images (meaning we should not change their values). One way to solve this would be to untie compel values from CRIU ones, using some mapping between the two sets when needed (i.e. in calls to compel_wait_task() and compel_resume_task()). Fortunately, we can avoid implementing this mapping by separating the ranges used by compel and criu. With this patch, compel is using values in range 0x01..0x7f, and criu is reusing those, plus adding more values in range 0x80..0xff for its own purposes. Note tha the values that are used inside images are not changed (as, luckily, they were all used by compel). travis-ci: success for compel uapi cleanups (rev2) Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-
Kir Kolyshkin authored
infect.h includes compel.h, and compel.h includes infect.h. Surely, due to include guards it will be sorted out, but we'd rather just include what we need. travis-ci: success for compel uapi cleanups Signed-off-by:
Kir Kolyshkin <kir@openvz.org> Reviewed-by:
Cyrill Gorcunov <gorcunov@openvz.org> Signed-off-by:
Pavel Emelyanov <xemul@virtuozzo.com> Signed-off-by:
Andrei Vagin <avagin@virtuozzo.com>
-