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(a)gibson.dropbear.id.au> wrote: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.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 dataWhat'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.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* 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(a)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.