[CRIU] [PATCHv4 0/4] libcriu

[Ruslan Kuprieiev]

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.

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?

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).


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?
> 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.