[CRIU] [PATCH 2/4] tools: add criu2text

[Ruslan Kuprieiev]

On 30.09.2014 12:54, Pavel Emelyanov wrote:
> On 09/30/2014 01:47 PM, Ruslan Kuprieiev wrote:
>> On 30.09.2014 12:14, Pavel Emelyanov wrote:
>>> On 09/30/2014 01:08 PM, Ruslan Kuprieiev wrote:
>>>> On 30.09.2014 11:12, Pavel Emelyanov wrote:
>>>>> On 09/19/2014 05:53 PM, Ruslan Kuprieiev wrote:
>>>>>> criu2text.py handles cmdline opts, opens files and reads\writes them
>>>>>> properly. images.py has a dict with MAGIC:pb_entry_type to specify what
>>>>>> type of pb entry we should read from image with magic MAGIC.
>>>>>> magic-gen.py parses include/magic.h to get all MAGIC values except
>>>>>> RAW and V1, because criu2text can't handle them for now.
>>>>> OK, I like the code, but let's rework the way tool works a little bit.
>>>>>
>>>>> 1. Right now, AFAIK, the tool turns one .img file into a set of .txt
>>>>> ones. Let's make tool convert _one_ file to _one_ file, e.g. core.img
>>>>> into core.txt. And the syntax should look like this:
>>>>>
>>>>> criu2text -i|--in <filename> -o|--out <filename>
>>>>>
>>>>> If <filename> == "-", then stdin/stdout is used.
>>>>>
>>>>> The conversion from .img to .txt would work automatically, the conversion
>>>>> back would have to know what kind of image we're working on. For this
>>>>> the tool can write the magic value as the first line (in a form of a
>>>>> comment if it makes sense).
>>>> In early criu2json it worked just as you described =).
>>>> In json it was easy to create a new message, but in pbtext it is a bit less
>>>> smooth. Well, we can separate msgs in txt file by special comments, e.g:
>>>> #0x12345                  magic
>>>> #0                              №
>>>> MSG0                          pb entry
>>>> #1                              №
>>>> MSG1                          pb entry
>>>> #2
>>>> MSG2
>>>> ........
>>>>
>>>> Does it look good to you?
>>>> Or maybe we should drop № and just leave # as a separator, e.g.:
>>>> #0x12345
>>>> MSG0
>>>> #
>>>> MSG1
>>>> #
>>>> MSG2
>>>>
>>>> ?
>>> Plz, show how the fdinfo-$pid.img would look like in this format.
>> #0x56213732
>> #0
>> id: 1
>> flags: 0
>> type: REG
>> fd: 0
>> #1
>> id: 2
>> flags: 0
>> type: REG
>> fd: 1
>> #2
>> id: 2
>> flags: 0
>> type: REG
>> fd: 2
>> #3
>> id: 3
>> flags: 1
>> type: REG
>> fd: 255
>>
>> Well, yeah, doesn't look great.
> But ready for scripted modification :)
>
>> But, if i'll figure out how to add some indent:
>> #0x56213732
>> #0
>>       id: 1
>>       flags: 0
>>       type: REG
>>       fd: 0
>> #1
>>       id: 2
>>       flags: 0
>>       type: REG
>>       fd: 1
>> #2
>>       id: 2
>>       flags: 0
>>       type: REG
>>       fd: 2
>> #3
>>       id: 3
>>       flags: 1
>>       type: REG
>>       fd: 255
> This is more human-readable. Can we make both outputs be available?

Sure. Maybe make raw format to look like:
#magic
0x12345
#0
MSG
#1
MSG
.....
?

> If stdio is a terminal, then use the 2nd, if not -- the 1st. And
> add the --format option with two (for now) meanings "raw" and "nice"
> (or how is this text called? pbtext?) that forcibly switches between
> them. In the future we'll be able to extend it to "--format json" :)

Well, adding --format json doesn't look hard. Btw, json is not that good for
scripted modification, right? Well, "#magic ... #0 ..." is better, right?

> BTW, in the "nice" version of the output it would be nice to replace
> the magic with some name, e.g. the criu proto file one.

Not sure about .proto files. Especially, because we need that magic to 
identify
pb entry, not just proto file where it is described. And because we need 
to write that
magic back when converting from text to img.
We might just add pb_entry name, e.g.

#magic
0x12345
#0 pagemap_head
MSG
#1 pagemap_entry
MSG
#2
MSG
#3
MSG

What do you think?

>> But I still like better the current "name.img into set of files
>> name.img.magic name.img.0...":
>>
>> $cat fdinfo-2.img.magic
>> 0x56213732
>> $cat fdinfo-2.img.0
>> id: 1
>> flags: 0
>> type: REG
>> fd: 0
>>
>> because it looks easier to modify and manage.
> If a format is non-suitable for shell piplining, it's not easy
> from my POV :)

Ok, I see.

>
> Thanks,
> Pavel
>
>