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@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
