On 24.04.20 18:20, Paul Durrant wrote:
-----Original Message-----
From: Julien Grall <jul...@xen.org>
Sent: 24 April 2020 17:04
To: Jürgen Groß <jgr...@suse.com>; Paul Durrant <p...@xen.org>;
xen-devel@lists.xenproject.org
Cc: Paul Durrant <pdurr...@amazon.com>
Subject: Re: [PATCH] docs/designs: re-work the xenstore migration document...
Hi,
On 24/04/2020 16:59, Jürgen Groß wrote:
On 24.04.20 17:44, Julien Grall wrote:
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.
That's very much up to the implementation. An implementation may decide
to bail out if the record is not an exact size.
It won't know. The record will be whatever size it says it is, and if the
format doesn't match what the implementation was expecting then it'll probably
crash.
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.
Of course, however I don't think a user will necessarily know it should
not do it. So how do you protect against misuse?
The stream is versioned. If information is vital then I'd expect the version to
be bumped, which should prevent a downgrade.
Uh, this is problematic. I agree that a downgrade will be prevented, but
merely via a crash. We won't have both versions active in parallel, but
the version we are updating to will make it or not. There is no way
back.
The general rule should be to be as forgiving to errors in the stream
as possible in order _not_ to have a crashing xenstored due to strict
parameter testing.
And in case there is a potential of problems it needs to be documented
and then its up to the user to follow the documentation.
Juergen
