Re: [Xen-devel] [PATCH v3 4/9] xen: add basic hypervisor filesystem support

[Jan Beulich <jbeulich@xxxxxxxx>]

On 04.02.2020 11:48, Jürgen Groß wrote:
> On 04.02.20 10:58, Jan Beulich wrote:
>> On 04.02.2020 10:21, Jürgen Groß wrote:
>>> On 04.02.20 09:48, Jan Beulich wrote:
>>>> On 04.02.2020 07:43, Jürgen Groß wrote:
>>>>> On 03.02.20 16:07, Jan Beulich wrote:
>>>>>> On 21.01.2020 09:43, Juergen Gross wrote:
>>>>>>> +struct xen_hypfs_direntry {
>>>>>>> +    uint16_t flags;
>>>>>>> +#define XEN_HYPFS_WRITEABLE    0x0001
>>>>>>> +    uint8_t type;
>>>>>>> +#define XEN_HYPFS_TYPE_DIR     0x0000
>>>>>>> +#define XEN_HYPFS_TYPE_BLOB    0x0001
>>>>>>> +#define XEN_HYPFS_TYPE_STRING  0x0002
>>>>>>> +#define XEN_HYPFS_TYPE_UINT    0x0003
>>>>>>> +#define XEN_HYPFS_TYPE_INT     0x0004
>>>>>>> +#define XEN_HYPFS_TYPE_BOOL    0x0005
>>>>>>> +    uint8_t encoding;
>>>>>>> +#define XEN_HYPFS_ENC_PLAIN    0x0000
>>>>>>> +#define XEN_HYPFS_ENC_GZIP     0x0001
>>>>>>
>>>>>> Meaning I can e.g. have a gzip-ed string or bool (or even dir)?
>>>>>> If this is just for "blob", why have separate fields instead of
>>>>>> e.g. BLOB_RAW and BLOB_GZIP or some such?
>>>>>
>>>>> gzip-ed string or blob are the primary targets.
>>>>>
>>>>> Maybe we want to have other encoding s later (Andrew asked for that
>>>>> possibility when I posted the patch for retrieving the .config file
>>>>> contents early last year).
>>>>
>>>> To me it would seem preferable if the contents of a blob
>>>> identified itself as to its format. But since this leaves
>>>> room for ambiguities I accept that the format needs
>>>> specifying. However, to me a gzip-ed string is as good as a
>>>> gzip-ed blob, and hence I still think sub-dividing "blob" is
>>>> the way to go, with no separate "encoding". Otherwise at the
>>>> very least a comment here would need adding to clarify what
>>>> combinations are valid / to be expected by callers.
>>>
>>> libxenhypfs is able to handle all possible combinations. I just don't
>>> think some of the combinations are making sense (gzip-ing a binary
>>> value of 4 bytes e.g. is nonsense).
>>>
>>> OTOH in case we'll add large arrays of longs in the future it might be
>>> beneficial to compress them in some way. So I'd like to keep type and
>>> encoding as separate information.
>>
>> Okay, I'm not entirely opposed. But I'd be curious if anyone
>> else has an opinion here.
> 
> I think content type and transport encoding should not be mixed up. They
> are orthogonal to each other and so they should be handled.

In principle I agree, but "blob" really covers anything or nothing
at all. Yes, if strings are meant to be possible to be gzip-ed,
then there is value in the separation. I'm not fully convinced
though that such compressed strings (Are you thinking about
.config here?) shouldn't simply be "blob" then, too.

Jan

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel