[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.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.


Xen-devel mailing list



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