[CRIU] p.haul and cpuinfo

[Pavel Emelyanov]

On 11/02/2015 11:54 PM, Adrian Reber wrote:
> On Mon, Nov 02, 2015 at 07:24:43PM +0300, Pavel Emelyanov wrote:
>> On 11/02/2015 07:15 PM, Adrian Reber wrote:
>>> Some CRIU supported architectures (all except x86) have not really
>>> implemented the dump cpuinfo functionality. Running criu cpuinfo dump on
>>> one of those arches returns 161 and that seems to break p.haul.
>>>
>>> The problem seems to come from cpuinfo_dump() and cpuinfo_check() which
>>> return -ENOTSUP. Which is correct as it is not implemented. I can work
>>> around this in p.haul by using the parameter '--force' but I would
>>> rather see this fixed correctly.
>>>
>>> Should this be fixed in cpuinfo_dump()/cpuinfo_check(), cr-service.c or
>>> in p.haul? 
>>
>> I would say it's CRIU's fix, all the more so p.haul has the option
>> --force that omits cpus validation.
> 
> So if cpuinfo_dump()/cpuinfo_check() are returning -ENOTSUP cr-service.c
> should return success=true via RPC interface? 

I don't agree. If cpuinfo image was not generated, then we should not
report success. 

> It sounds like another
> additional message is needed to let p.haul know that the cpuinfo dump
> did not actually fail but that it is unsupported.

How about setting the cr_errno in criu_resp to ENOTSUP in that case?
The field is there, it's optional and we can (and should) use it for
additional error reporting and not supported cpu checks seem to be
good candidates for that.

-- Pavel