[CRIU] [PATCH 2/2]v2 service: add support for check request

Pavel Emelyanov xemul at parallels.com
Tue Nov 19 10:40:02 PST 2013


On 11/20/2013 02:32 AM, Ruslan Kuprieiev wrote:
> On 19.11.2013 21:37, Pavel Emelyanov wrote:
>> On 11/19/2013 06:03 PM, Ruslan Kuprieiev wrote:
>>> On 19.11.2013 12:10, Pavel Emelyanov wrote:
>>>> On 11/19/2013 03:44 PM, Ruslan Kuprieiev wrote:
>>>>> On 19.11.2013 11:36, Pavel Emelyanov wrote:
>>>>>> On 11/18/2013 06:25 PM, Ruslan Kuprieiev wrote:
>>>>>>> Signed-off-by: Ruslan Kuprieiev <kupruser at gmail.com>
>>>>>>> ---
>>>>>>>     cr-service.c | 37 +++++++++++++++++++++++++++++++++++++
>>>>>>>     1 file changed, 37 insertions(+)
>>>>>>>
>>>>>>> diff --git a/cr-service.c b/cr-service.c
>>>>>>> index 65710fd..c337fce 100644
>>>>>>> --- a/cr-service.c
>>>>>>> +++ b/cr-service.c
>>>>>>> @@ -217,6 +217,41 @@ exit:
>>>>>>>     	return success ? 0 : 1;
>>>>>>>     }
>>>>>>>     
>>>>>>> +/*
>>>>>>> + * Only checks criu ability to work in this enviroment.
>>>>>>> + */
>>>>>>> +static int check_using_req(int sk, CriuOpts *req)
>>>>>>> +{
>>>>>>> +	bool success = false;
>>>>>>> +	CriuResp msg = CRIU_RESP__INIT;
>>>>>>> +	CriuCheckResp resp = CRIU_CHECK_RESP__INIT;
>>>>>>> +
>>>>>>> +	if (setup_opts_from_req(sk, req) == -1) {
>>>>>>> +		pr_perror("Arguments treating fail");
>>>>>>> +		goto exit;
>>>>>>> +	}
>>>>>>> +
>>>>>>> +	if (cr_check() < 0) {
>>>>>>> +		pr_perror("The kernel support isn't up-to-date");
>>>>>>> +		goto exit;
>>>>>>> +	}
> 
> Here, if cr_check() hasn't returned 0, it means that resp.kernel = 
> false, and it is by default false. If cr_check has returned 0, than we 
> set resp.kernel to true.

And success to true as well. Show me how resp.success can be != resp.kernel.

>>>>>>> +
>>>>>>> +	resp.kernel = true;
>>>>>> Always true argument is pointless.
>>>>> But resp.kernel = false after init. If cr_check() does not fail, we set
>>>>> resp.kernel to true, and if cr_check() does fail - resp.kernel = false.
>>>> So we have two types of responses:
>>>>
>>>> * kernel = true,  success = true  for OK
>>>> * kernel = false, success = false for not-OK
>>>>
>>>> Why is just success = <success-or-not> not enough?
>>> Here is what we've got:
>>>
>>> -- resp.success == false  -- options are wrong or something bad happened
>>> and check wasn't done
>>>
>>> -- resp.success == true and resp.check.kernel == true -- check was done
>>> and kernel features are ok
>>>
>>> -- resp.success == true and resp.check.kernel == false -- check was done
>>> and kernel features are not ok
>> I don't see this in the code -- resp.success = true and resp.kernel = true
>> are set together in one place.
>>
>>> And also we may easily add some more fields for more complete system
>>> state analysis.
>>>
>>>>>>> +
>>>>>>> +	success = true;
>>>>>>> +exit:
>>>>>>> +	msg.type = CRIU_REQ_TYPE__CHECK;
>>>>>>> +	msg.success = success;
>>>>>>> +	msg.check = &resp;
>>>>>>> +
>>>>>>> +	if (send_criu_msg(sk, &msg) == -1) {
>>>>>>> +		pr_perror("Can't send response");
>>>>>>> +		success = false;
>>>>>>> +	}
>>>>>>> +
>>>>>>> +	return success ? 0 : 1;
>>>>>>> +}
>>>>>>> +
>>>>>>>     static int cr_service_work(int sk)
>>>>>>>     {
>>>>>>>     	CriuReq *msg = 0;
>>>>>>> @@ -233,6 +268,8 @@ static int cr_service_work(int sk)
>>>>>>>     		return dump_using_req(sk, msg->opts);
>>>>>>>     	case CRIU_REQ_TYPE__RESTORE:
>>>>>>>     		return restore_using_req(sk, msg->opts);
>>>>>>> +	case CRIU_REQ_TYPE__CHECK:
>>>>>>> +		return check_using_req(sk, msg->opts);
>>>>>>>     
>>>>>>>     	default: {
>>>>>>>     		CriuResp resp = CRIU_RESP__INIT;
>>>>>>>
>>>>> .
>>>>>
>>> .
>>>
>>
> 
> .
> 




More information about the CRIU mailing list