Re: [PATCH] docs/designs: re-work the xenstore migration document...

[Julien Grall <julien@xxxxxxx>]

On 24/04/2020 15:51, Jürgen Groß wrote:
> On 24.04.20 16:38, Julien Grall wrote:
> > Hi,
> >
> > On 24/04/2020 15:26, Jürgen Groß wrote:
> > > > +```
> > > > +    0       1       2       3       4       5       6       7    octet
> > > > ++-------+-------+-------+-------+-------+-------+-------+-------+
> > > > +| type                          | len                           |
> > > > ++-------------------------------+-------------------------------+
> > > > +| body
> > > > +...
> > > > +|       | padding (0 to 7 octets)                               |
> > > > ++-------+-------------------------------------------------------+
> > > > +```
> > > > +
> > > > +NOTE: padding octets here and in all subsequent format 
> > > > specifications must be
> > > > +      zero, unless stated otherwise.
> > > What about: "... are written as zero and should be ignored on read."
> > I would rather not say "ignored" because it doesn't allow us to extend 
> > the record if needed in a safe way. The read side should abort if it 
> > sees an other value than 0 in the padding.
> I'd rather ignore unknown fields. This allows to add optional data
> without having to special case it. 
You will need a special case for 0 in any case.

> Writing zeroes is the important part
> here, of course.
>
> Ignoring those fields would e.g. enable a downgrade more easily, while
> aborting could make that impossible.
You are assuming the fields may contain optional data. Now imagine, we 
realize in a few months we missed some important fields. How would you 
describe the required fields?
I can see two ways:
    1) Re-using the padding fields if possible
    2) Extending the record

If you re-use the padding fields, then when you downgrade you may lose 
information. If you extend the size of the record, then you can't downgrade.
Cheers,

--
Julien Grall