On 7/14/23 13:08, Rob Wing wrote:
On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms <mgro...@shrew.net
<mailto:mgro...@shrew.net>> wrote:
I see a need to define a format for bhyve so it's possible to mix
different sections and encodings inside a unified stream. But all the
data in your nvlist example above can be easily be represented as text.
We already have JSON, YAML, XML, etc ... By adopting an preexisting
format, we could retain the snapshot structure instead of lifting it up
into the stream format. Even if we decide to break the structure up
into
different nvlist stream sections, using a common format would allow
other tools to more easily parse and validate the structure inside
these
sections. Isn't that a good thing? Is there a reason we're trying to
reinvent the wheel here?
Does JSON support storing binary data? I'm under the impression that it
does not.
Hi Rob,
When we spoke to John Baldwin and others in the community about being
able to remove the #ifdef's from the snapshot code, we were told that
copying binary data structures to a state file was the wrong approach
and that a better method needed to be provided. We agreed. That's why
the following work was undertaken to provide a rich file format that
describes the component values of device's state instead of codifying
the c structure in the file format ...
https://reviews.freebsd.org/D29262
When Vitaliy added comments to that review WRT an nvlist based approach,
I assumed that meant preserving the decomposition of device information
that the UPB team spent so much effort trying to extract. I should have
read the original file format proposal email before I replied as I tried
too hard to interpret it info through that lens. My mistake.
If Vitaliy, and apparently you, favor the continued practice of copying
data from c structure pointers directly into files to save device state,
I have no more comments on that approach. Maybe John or UPB will chime
in here with feedback that's more helpful.
-Matthew
