[CRIU] [PATCH 3/3] libcriu: allow user to specify service fd
Ruslan Kuprieiev
kupruser at gmail.com
Thu Jul 16 05:02:52 PDT 2015
On 07/16/2015 03:00 PM, Pavel Emelyanov wrote:
> 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.
>
Oh, didn't think about that. Will fix that, thanks!
More information about the CRIU
mailing list