[CRIU] [PATCH 1/3] libcriu: use criu_opts structure to keep all the options
Pavel Emelyanov
xemul at parallels.com
Thu Jul 16 05:01:34 PDT 2015
On 07/16/2015 02:44 PM, Ruslan Kuprieiev wrote:
>
>
> On 07/16/2015 02:40 PM, Pavel Emelyanov wrote:
>> On 07/16/2015 02:40 PM, Ruslan Kuprieiev wrote:
>>> On 07/16/2015 02:31 PM, Pavel Emelyanov wrote:
>>>> On 07/15/2015 04:45 AM, Ruslan Kuprieiev wrote:
>>>>> ---
>>>>> Makefile | 2 +-
>>>>> lib/criu.c | 469 ++++++++++++++++++++++++-------------------------------------
>>>>> lib/criu.h | 81 ++++++-----
>>>>> 3 files changed, 228 insertions(+), 324 deletions(-)
>>>>>
>>>>> diff --git a/Makefile b/Makefile
>>>>> index 6ed4c90..d67ed0b 100644
>>>>> --- a/Makefile
>>>>> +++ b/Makefile
>>>>> @@ -161,7 +161,7 @@ SYSCALL-LIB := $(ARCH_DIR)/syscalls.built-in.o
>>>>> ARCH-LIB := $(ARCH_DIR)/crtools.built-in.o
>>>>> CRIU-SO := libcriu
>>>>> CRIU-LIB := lib/$(CRIU-SO).so
>>>>> -CRIU-INC := lib/criu.h include/criu-plugin.h include/criu-log.h protobuf/rpc.proto
>>>>> +CRIU-INC := lib/criu.h include/criu-plugin.h include/criu-log.h protobuf/rpc.proto protobuf/rpc.pb-c.h
>>>> Why is this required?
>>> Because we now include rpc.pb-c.h into libcriu header, so we need to
>>> install it too.
>> Any why do we include it?
>>
> To keep CriuOpts in criu_opts structure, so we don't hide it behind void
> pointer,
> which makes everything a lot more clear for both libcriu user and
> developer =).
But the libcriu user doesn't need to know the internals of CriuOpts, he
only needs a pointer Plz, find a way not to reveal this structure to public
use.
More information about the CRIU
mailing list