[PATCH 0/2] Fancier version handling for migration
This series introduces more flexible version handling for our device state migration stream. This is based on my previous assorted migration improvements series. David Gibson (2): migrate: Merge protocol version information into one table migrate: More sophisticated versioning migrate.c | 213 +++++++++++++++++++++++++++++++++++------------------- migrate.h | 73 +++++++++++-------- 2 files changed, 179 insertions(+), 107 deletions(-) -- 2.48.1
Currently information on protocol version specific things is split between
struct migrate_data, which lists the memory blocks to save and restore and
struct migrate_target_handlers which gives the per-version (target) pre and
post handlers to run.
In addition, despite having already looked up the version in the
migrate_data table at the top-level, we look it up again in
migrate_target_state() and do a similar lookup in target_handlers in
migrate_target_{pre,post}().
Combine the per-version information into a single struct migrate_version,
look it up once at the top level, then pass that through to the other
functions within migrate_meta.
Signed-off-by: David Gibson
On Fri, 31 Jan 2025 15:52:14 +1100
David Gibson
+/** + * struct migrate_meta - Migration metadata + * @version: Version number, host order + * @v: Version information + * @bswap: Source has opposite endianness + * @peer_64b: Source uses 64-bit void * + * @time_64b: Source uses 64-bit time_t + * @flow_size: Size of union flow in source + * @flow_sidx_size: Size of struct flow_sidx in source + */ +struct migrate_meta { + uint32_t version; + const struct migrate_version *v; + bool bswap; + bool source_64b; + bool time_64b; + size_t flow_size; + size_t flow_sidx_size; +};
What's the purpose of this, if this information should go away quite soon (even before merge, perhaps)? -- Stefano
On Fri, Jan 31, 2025 at 06:53:44AM +0100, Stefano Brivio wrote:
On Fri, 31 Jan 2025 15:52:14 +1100 David Gibson
wrote: +/** + * struct migrate_meta - Migration metadata + * @version: Version number, host order + * @v: Version information + * @bswap: Source has opposite endianness + * @peer_64b: Source uses 64-bit void * + * @time_64b: Source uses 64-bit time_t + * @flow_size: Size of union flow in source + * @flow_sidx_size: Size of struct flow_sidx in source + */ +struct migrate_meta { + uint32_t version; + const struct migrate_version *v; + bool bswap; + bool source_64b; + bool time_64b; + size_t flow_size; + size_t flow_sidx_size; +};
What's the purpose of this, if this information should go away quite soon (even before merge, perhaps)?
Soon, but not yet. I don't want to break the stuff you're working on until I have something else to replace it. -- 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
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
* 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
On Fri, 31 Jan 2025 15:52:15 +1100
David Gibson
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? 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
--- 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. -- Stefano
On Fri, Jan 31, 2025 at 06:53:48AM +0100, Stefano Brivio wrote:
On Fri, 31 Jan 2025 15:52:15 +1100 David Gibson
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
--- 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
participants (2)
-
David Gibson
-
Stefano Brivio