qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [Qemu-block] storing machine data in qcow images?


From: Michael S. Tsirkin
Subject: Re: [Qemu-devel] [Qemu-block] storing machine data in qcow images?
Date: Tue, 5 Jun 2018 23:06:41 +0300

On Tue, Jun 05, 2018 at 02:54:07PM -0500, Eric Blake wrote:
> On 06/05/2018 02:47 PM, Michael S. Tsirkin wrote:
> 
> > > > Layer 1:
> > > >     The string shall always be a JSON 'object'; i.e. of the form
> > > >      { "something": ... , "more": ... }
> > > > 
> > > >     The key strings shall be non-null and non-empty and shall
> > > >     be unique.
> 
> > > 
> > > I think it would be simpler if layer 0 simply provided a list of
> > > names/value pairs, where names are ascii strings, and values are
> > > binary data[1].  It would make layer 1 unnecessary, and allow (3)
> > > and (4) to happen.
> > > 
> > > [1] In other words, Rich's proposal of "named blobs":
> > > https://www.mail-archive.com/address@hidden/msg37856.html
> > 
> > I think simple is beautiful, too. But assuming they
> > really are binary how are blobs encoded?
> > Did binary really mean UTF-8 here?
> 
> Binary blobs can always be base64 encoded for representation within a valid
> JSON UTF-8 string (and we already have several QMP interfaces that utilize
> base64 encoding to pass through what is otherwise invalid UTF-8).  It does
> inflate things slightly compared to a format that allows a raw length
> coupled with raw data, but that is not necessarily a problem.

OK so what's proposed here is something like the following:

[A-Za-z][^=\0]*=[^\0]*

Sound reasonable?

How about a fixed key at the beginning to specify the format?

E.g. 16 first bytes:

qcow2-format=00\0

anything else in first 16 bytes means some other format?

> -- 
> Eric Blake, Principal Software Engineer
> Red Hat, Inc.           +1-919-301-3266
> Virtualization:  qemu.org | libvirt.org



reply via email to

[Prev in Thread] Current Thread [Next in Thread]