[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