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

[Jürgen Groß <jgross@xxxxxxxx>]

On 24.04.20 17:44, Julien Grall wrote:
> 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.
0 will need to have the "no optional data" semantics.

> > 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.
If I extend the record and do a downgrade I'm losing the information,
too, as the old version won't read it in any case. BTW, extending the
record is no problem, as the length is stored in the header. Unknown
records (and extensions) will be just ignored when reading.

In your case when reusing the paddings and doing a downgrade you would
crash, as the paddings are no longer zero.

In case a downgrade should not be done due to vital information loss
then you should just not do it.


Juergen