Re: [PATCH 2/2] migrate: More sophisticated versioning

[David Gibson <david@gibson.dropbear.id.au>]

[-- Attachment #1: Type: text/plain, Size: 3096 bytes --]

On Fri, Jan 31, 2025 at 06:53:48AM +0100, Stefano Brivio wrote:
> On Fri, 31 Jan 2025 15:52:15 +1100
> David Gibson <david@gibson.dropbear.id.au> wrote:
> 
> > At present the header for our device state migration stream is sent as
> > a buffer in the sections array, like anything else.  It contains both
> > version information, and details on the source ABI which are specific to
> > v1 of the migration protocol.  Alter this for greater flexibility:
> > 
> >  * We separate out a minimal fixed header, which we will need to keep for
> >    every future version, from a version specific header, containing (for
> >    v1) the ABI data
> 
> What's the purpose of this if there should be no ABI data?

We might get rid of the ABI data, but it seems very likely to me that
future protocol versions will want some sort of header / metadata
information.  More specifically, it seems likely to me that they'll
want some sort of meta information that needs to be checked /
processed, but not read into a long term data structure as-is.  The
read_header_v() hook allows us to do that easily.

> I have this for the moment:
> 
> 	/* Immutable part of header structure: keep these two sections at the
> 	 * beginning, because they are enough to identify a version regardless
> 	 * of metadata.
> 	 */
> 	.magic		= MIGRATE_MAGIC,
> 	.version	= htonl_constant(MIGRATE_VERSION),
> 	/* End of immutable part of header structure */
> 
> ...which to be honest already felt like wasted effort, despite being
> just two comments.
> 
> >  * Handle both the headers separately from the data sections making for
> >    better symmetry between the source and target sides
> >  * Add a "compat_version" field.  This will allow us to make future
> >    protocol extensions which are backwards compatible with older targets,
> >    while retaining the ability to also make breaking protocol extensions.
> > 
> > This establishes a minimal header with fixed representation to maintain
> > for all future versions.
> > 
> > Signed-off-by: David Gibson <david@gibson.dropbear.id.au>
> > ---
> >  migrate.c | 157 ++++++++++++++++++++++++++++++++++++++++--------------
> >  migrate.h |  26 ++++++---
> >  2 files changed, 138 insertions(+), 45 deletions(-)
>                     ^^^
> 
> ...is this really a good idea if we want to drop this right away? I
> might be missing something but I think it would more sense to focus on
> the "targeted" data transfer instead.

I'm seeing this as preliminary steps towards doing the targeted data
transfer.  For one thing I want to be able to experiment with that
(let's call it v2) without breaking your v1 stuff.  Even if we drop v1
before merge, I think that's useful during dev.

But even without that, I think I'm going to want some sort of "header"
information for v2, and this provides an easy way to hook that in.

-- 
David Gibson (he or they)	| I'll have my music baroque, and my code
david AT gibson.dropbear.id.au	| minimalist, thank you, not the other way
				| around.
http://www.ozlabs.org/~dgibson

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]