Re: BHYVE SNAPSHOT image format proposal

On 7/14/23 13:08, Rob Wing wrote:
> 
> 
> On Fri, Jul 14, 2023 at 9:40 AM Matthew Grooms <mgrooms@shrew.net 
> <mailto:mgrooms@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