[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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

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.


Xen-devel mailing list



Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.