[CRIU] [RFC] Introduce v1.1 image format

[Ruslan Kuprieiev]

On 03/31/2015 04:25 PM, Pavel Emelyanov wrote:
> On 03/31/2015 04:21 PM, Ruslan Kuprieiev wrote:
>> On 03/31/2015 04:10 PM, Pavel Emelyanov wrote:
>>> On 03/31/2015 04:07 PM, Ruslan Kuprieiev wrote:
>>>> On 03/31/2015 03:29 PM, Pavel Emelyanov wrote:
>>>>> Hi,
>>>>>
>>>>> Right now we have too many criu-specific file types -- effectively
>>>>> every new image file we add is a new "type", we invent a new magic
>>>>> number for it and put only it into the header.
>>>>>
>>>>> One of the difficulty with this approach is that we can't nicely
>>>>> teach the "file" utility to spot CRIU-specific files. Too many
>>>>> magic should be added and we would have to add new magic numbers
>>>>> for every new image type we introduce.
>>>> But this patch leaves inventory.img intact, so "file" utility might as
>>>> well just be taught to spot only inventory magic, because our images
>>>> are spread across directory anyway.
>>> Yes, and asking "file" for what the rest is would result in an unhelpful
>>> answer -- "data" :)
>> But we still have stats and irmap images, so "file" utility will say
>> that it is "data".
> Unless we add their magics into files's database.

Not sure that they have unique magic.

> The intention of this
> set is to a) reduce the number of magics to add (will be 4) and b) to
> make it possible to add more image files (if needed) without updating
> the file's database.

But it might as well add some confusion -- we still require a directory
to work with and the only file that actually matters is inventory.img.
So one non-inventory file with criu magic doesn't worth nothing, but
the end user might be confused with "file" utility telling that this 
particular
i.e. core-1234.img standalone file is "criu image file", and he might
think that it is sufficient to work with.

>>>> Do we really need these changes?
>>> With this we will only need to add 4 magic-s in the file database.
>>>
>>>> This set also adds another level of confusing complexity to our images
>>>> structure.
>>>> Maybe we should rather suggest focusing on V2 images, to make them
>>>> perfect and
>>>> not create an intermediate version of non-backward compatible images?
>>> V2 would be great, but they will be backward incompatible too :) So
>>> from this perspective v1.1 is not worse.
>> It is worse because it adds _new_ backward incompatible version with
>> doubtful advantages, that could be just saved for later to be implemented
>> in V2.
> Yes, I agree. But converting from v1.1 to v1 can be done quite easily, we
> don't need to patch CRIT heavily to achieve that.

True, I'm not scared with the required changes, but with the general 
necessity
of v1.1 with such a minor changes.

> I would even say, that in the worst case we could release criu-1.5.2 or
> criu-1.4.1 that will support v1.1. The patch for that would be trivial.
> And it's not the case for v2.
>
> -- Pavel