[CRIU] [PATCH 2/6] crit: add --format hex option

Ruslan Kuprieiev kupruser at gmail.com
Tue Aug 11 10:57:55 PDT 2015


Hi Christopher

I don't think this is that much necessary, but I thought it was the
less ugly way at that time. If I recall correctly, one of the main factors
was that protobuf compiler can't place compiled files other that where
the original *.proto file is situated, and I was not happy about that way
of system pollution.

I would highly appreciate if you could fix it in a nice way.

Thanks,
Ruslan

On 08/11/2015 08:32 PM, Christopher Covington wrote:
> On 01/19/2015 09:10 AM, Ruslan Kuprieiev wrote:
>> >Pavel reported that decimal values for some fields are hard to read,
>> >because people used to see hex values in there. Unfortunately, json
>> >doesn't support hex representation of integers, so we can only store
>> >them as hex strings. Not all field need to be represented as hex
>> >strings, so this set introduces a custom field option called "criu"
>> >to use in our proto files. One should use [(criu).hex = true] to mark
>> >which field should be represented as a hex string. pb2dict module
>> >from pycriu package will look into field options and if he finds that
>> >criu.hex is set to True, it will convert such field to/from hex string.
>> >Though, such behaviour is optional and user can request it by specifying
>> >  --format hex when calling crit decode("crit encode" in its turn, detects
>> >such fields automatically and doesn't require any special cmdline options
>> >to be set).
>> >
>> >We need our proto files to compile with both protoc and
>> >protoc-c compilers, which requires creating google/protobuf
>> >directory with a symlink to/usr/include/google/protobuf/
>> >descriptor.proto to make protoc-c and generated c files happy.
> This is not a nice presumption, that the user has a distribution package of
> protobuf installed at that path, and if they do, that it's the version they
> want criu/crit to be built against/use.
>
> Can you please elaborate on why you think this is necessary? We'll probably be
> cooking up a patch to change this.
>

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openvz.org/pipermail/criu/attachments/20150811/bf4a9aee/attachment.html>


More information about the CRIU mailing list