[CRIU] [PATCH 3/3] libcriu: allow user to specify service fd

Pavel Emelyanov xemul at parallels.com
Thu Jul 16 05:00:28 PDT 2015


On 07/16/2015 02:55 PM, Ruslan Kuprieiev wrote:
> 
> 
> On 07/16/2015 02:46 PM, Ruslan Kuprieiev wrote:
>>
>>
>> On 07/16/2015 02:32 PM, Pavel Emelyanov wrote:
>>>> @@ -122,12 +134,21 @@ int criu_dump_iters(int 
>>>> (*more)(criu_predump_info pi));
>>>>    */
>>>>     typedef struct {
>>>> -    CriuOpts    *rpc; /* Generic RPC options in protobuf format */
>>>> -    int        (*notify)(char *action, criu_notify_arg_t na);
>>>> +    CriuOpts        *rpc; /* Generic RPC options in protobuf format */
>>>> +    int            (*notify)(char *action, criu_notify_arg_t na);
>>>> +    enum criu_service_comm    service_comm;
>>>> +    char            *service_address;
>>>> +    int            service_fd;
>>> 3 fields is overkill :) Just put -1 into service_fd if it's not 
>>> initialized
>>> and NULL in _address and check them.
>>
>> I did that because of my next patch(didn't send it yet) implementing 
>> swrk call for users
>> that don't want to keep criu service running. There, we will have 
>> CRIU_COMM_SWRK to
>> indicate that. And overall current implementation is quite flexible 
>> and just looks much
>> more convenient than NULL and -1 checking.
>>
> 
> Let me explain a bit more =). So I've also thought about error handling 
> and what if
> user accidentally(or intensionally) specifies both fd and service 
> address. How do
> we decide which has higher priority? If we use service_comm, we do what 
> we're told
> in there. So it just looks a lot nicer and cleaner.
> Does it make sense?

OK, then make _address and _fd be a union.



More information about the CRIU mailing list