[CRIU] [PATCHv4 0/4] libcriu

[Pavel Emelyanov]

On 09/04/2013 10:01 AM, Ruslan Kuprieiev wrote:
> On 09/03/2013 10:47 PM, Pavel Emelyanov wrote:
>> All signed-off-by-s get flushed away :(
> My apologies...
> 
> On 09/03/2013 10:48 PM, Pavel Emelyanov wrote:
>> On 09/03/2013 06:44 PM, Ruslan Kuprieiev wrote:
>> +/* return codes */
>> +#define CRIU_DUMP_FAIL		-1
>> +#define CRIU_RESUME		1	/* when program is restored */
>> +#define CRIU_DUMP_SUCCESS	0	/* when CRIU_DUMP_AND_CONTINUE is set */
>> +#define CRIU_OLD_VERSION	-2	/* when libcriu ver. > criu ver. */
>> I'd turn ">" into "!="
>>
> Ok, will do.
> 
> On 09/03/2013 10:50 PM, Pavel Emelyanov wrote:
>> On 09/03/2013 06:44 PM, Ruslan Kuprieiev wrote:
>>
>>> +static CriuDumpArgs *args;
>> No way. The criu_alloc_args() should alloc and _return_ the
>> pointer to the CriuDumpArgs to the caller. This pointer should
>> be used allover the criu_xxx() calls below.
>>
>>> +static char *service_addr;
>>> +
>>> +int criu_alloc_args(void)
>>> +{
>>> +	args = malloc(sizeof(CriuDumpArgs));
>>> +	if (args == NULL) {
>>> +		perror("Can't allocate memory");
>> I doubt that library should emit any messages.
>>
> Even error messages? But it will give information to user, if he is 
> doing something wrong.

Error codes should do that. Logging may be configured in a strange way and
simple perror() may do bad things.

> On 09/03/2013 10:51 PM, Pavel Emelyanov wrote:
>> On 09/03/2013 06:44 PM, Ruslan Kuprieiev wrote:
>>> cr_service() is function to start daemon, that will create unix domain
>>> socket and will listen for requests from libcriu on it. If request is
>>> obtained, it will fork() child, that will recv, process arguments and
>>> dump program.
>>>
>>> +child_err:
>>> +	ret = CRIU_DUMP_FAIL;
>>> +child_out:
>>> +	if (send(client_fd, &ret, sizeof(ret), 0) == -1)
>>> +		pr_perror("Can't send msg to lib");
>>> +
>>> +	close(client_fd);
>>> +	exit(1);
>>> +}
>> Response from service should also be a protobuf message.
>>
> Is it planned to send back some additional data, except return flag?

It can be so, and since we're doing protobuf-RPC everything should be
in protobuf.

> On 09/03/2013 10:52 PM, Pavel Emelyanov wrote:
>> On 09/03/2013 06:44 PM, Ruslan Kuprieiev wrote:
>>
>>> +message criu_dump_args {
>>> +	required int32 version_major 	= 1;
>>> +	required int32 version_minor 	= 2;
>>> +	required int32 images_dir_fd	= 3;
>>> +	required uint64 flags		= 4;
>> After a bit more thinking, I believe, that we should stop using
>> bit flags and replace them with protobuf's bool fields.
>>
> Do you mean, like in opts? For example, i should add "state" that will 
> be one of 4 values(TASK_DEAD, TASK_ALIVE etc).

No, more like cmdline options. In this case it should required bool leave_running.

> 
> On 09/03/2013 11:00 PM, Pavel Emelyanov wrote:
>> On 09/03/2013 06:44 PM, Ruslan Kuprieiev wrote:
>>> criu_dump_me() can be used by program to dump itself.
>>> Program need to call criu_allocate_args() to prepare arguments and then
>>> it can set them using criu_set* functions. criu_set* functions are used
>>> instead of give user access to arguments itself, so user will not mess
>>> with protobuf. libcriu.h is to be used by user program.
>>>
>>>
>>> +	if (send_fd(socket_fd, NULL, 0, args->images_dir_fd) == -1) {
>>> +		perror("Can't send file descriptor");
>>> +		return CRIU_DUMP_FAIL;
>>> +	}
>> Oh, and one more thing. This args->images_dif_fd is totally useless in the
>> dump args _if_ we send this fd, since on serivice side, this value would
>> change.
> Should I do like this: copy images_dir_fd to some tmp variable, set 
> args->has_images_dir_fd = 0, send  args, send tmp variable?

For now yes, but I'm thinking about not sending descriptors over unix sockets
at all (see below).

>> But, it looks like sending a file descriptor can only easily be done in C
>> code, but in e.g. Python or Java this is painful, so we probably would have
>> to reconsider the way we send images dir fd to the service (need more
>> thinking).
>>
> Is libcriu in the same address namespace as user program? If so, user 
> program could pass folder path to libcriu, and, as libcriu has the same 
> uid\gid\pid, it could open it(just like user program could) and send fd 
> to criu. So it won't matter, what language user program is using.

Java can't use libcriu.so. The intention is to describe the protocol in
documentation and make protobuf messages open. Thus in any language, that
has protobuf bindings it would be possible to send 'dump-me' request.

Thanks,
Pavel