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

[Jürgen Groß <jgross@xxxxxxxx>]

On 04.02.20 12:28, Jan Beulich wrote:
> 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.
With a library on top of the hypercall it is easy to hide the encoding
from the standard user. So even with .config being held in gzip-ed
format in the hypervisor the xenhypfs tool will still just print the
textual form of it when reading the associated node. This is different
from sysfs or procfs of the Linux kernel, where the raw data is
presented at the primary user interface. Additionally this enables us
to avoid having to specify the compression format as a stable ABI. We
could at any time switch to uncompressed format without problem.


Juergen

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