Re: [Qemu-devel] [PATCH 1/1] parallels: add format spec

[Denis V. Lunev]

On 11/17/2015 06:54 PM, Eric Blake wrote:
> On 11/16/2015 04:52 AM, Denis V. Lunev wrote:
> > From: Vladimir Sementsov-Ogievskiy <address@hidden>
> >
> > This specifies Parallels image format as implemented in Parallels Cloud
> > Server 6.10
> Are we the canonical location of the specification?  If not, do we risk
> getting out of sync with the canonical Parallels Cloud Server
> documentation, in which case, wouldn't it be better to point to a URL of
> the externally-maintained spec rather than duplicating it here?
the problem is that this documentation is not published in the
other place and for me keeping it here is a shorter way than
getting the page on the official virtuozzo.com
Thus I would like to get this place a canonical location of it.

At the moment I can make a promise to keep it actual. There
are no new features in the visible scope planned for PCS and
they can not appear in Parallels Server without me.

There is another purpose though. This spec gives a base for
Vladimir to implement named dirty bitmap support for
Parallels images in QEMU as they are implemented in PCS.
This is the main goal of this submission.


> > +++ b/docs/specs/parallels.txt
> > @@ -0,0 +1,218 @@
> > += Parallels Expandable Image File Format =
> > +
> Is this document okay under the default GPLv2+ license, or does it need
> to explicitly call out a different license?

GPLv2 is OK for us. We can state this explicitly in
the header if this is necessary.

> > +== Header ==
> > +
> > +The header is placed at the start of an image and contains the following
> > +fields:
> > +
> > +    char      magic[16]
> > +              Must contain "WithoutFreeSpace" or "WithouFreSpacExt".
> > +
> > +    uint32    version
> > +              Must be 2.
> > +
> You may want to compare to the qcow2 spec, which also lists expected
> byte offsets for each field (rather than having to count how many
> earlier fields of which widths were specified).
this would be nice to implement unit tests. We will add this
for sure! Thank you for an idea.

Den