From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=none (p=none dis=none) header.from=gibson.dropbear.id.au Authentication-Results: passt.top; dkim=pass (2048-bit key; secure) header.d=gibson.dropbear.id.au header.i=@gibson.dropbear.id.au header.a=rsa-sha256 header.s=202502 header.b=VKjQM3sP; dkim-atps=neutral Received: from mail.ozlabs.org (mail.ozlabs.org [IPv6:2404:9400:2221:ea00::3]) by passt.top (Postfix) with ESMTPS id 93FEC5A0271 for ; Tue, 04 Feb 2025 04:43:27 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202502; t=1738640581; bh=Ljt7tgHAE/RyuFoYZFCPl4MUfo/5ns+aeVPmZDP5FYs=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=VKjQM3sP2oPh7p2hFzS6KgYv/NEZ7TPtAu36iRq/CBFO+xiXbgrWutin5JUW6pRgq Ehw5mXgtJeG/kB8y/ZcS1qhwUwzDkBAfg1hjTW6omzkhaVSqvZmuojT7PO4NZG9Cur xmoEoG57FeOmB/aZ62lhOlmRHQUSXfI4249R+24+k7xz+D0t8O+58YZgGypZV/tck0 0Fwhw3BPpoJOqvvjGd/OXwlatYivk4C1cc46RkJySZvIhdQoSWa1WEl0ZvSr70J3c6 hQzGCV8apTenvjx888AwqMoqDAmb1W6cvhn/ymYRCmRucIVFrgSE1j8II7+tjO85ab D2s582P86lb2g== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4Yn8Mn3wNjz4wnp; Tue, 4 Feb 2025 14:43:01 +1100 (AEDT) Date: Tue, 4 Feb 2025 14:36:25 +1100 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH 6/6] migrate: Make migration handlers simpler and more flexible Message-ID: References: <20250203092615.500163-1-david@gibson.dropbear.id.au> <20250203092615.500163-7-david@gibson.dropbear.id.au> <20250203112003.1bcc7acd@elisabeth> <20250204011209.7a28decf@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="bKFMwl7rxdP3Qt9n" Content-Disposition: inline In-Reply-To: <20250204011209.7a28decf@elisabeth> Message-ID-Hash: 5XJP6PDSVGU6D5NYQOCWVOGFO3F5LNXC X-Message-ID-Hash: 5XJP6PDSVGU6D5NYQOCWVOGFO3F5LNXC X-MailFrom: dgibson@gandalf.ozlabs.org X-Mailman-Rule-Misses: dmarc-mitigation; no-senders; approved; emergency; loop; banned-address; member-moderation; nonmember-moderation; administrivia; implicit-dest; max-recipients; max-size; news-moderation; no-subject; digests; suspicious-header CC: passt-dev@passt.top X-Mailman-Version: 3.3.8 Precedence: list List-Id: Development discussion and patches for passt Archived-At: Archived-At: List-Archive: List-Archive: List-Help: List-Owner: List-Post: List-Subscribe: List-Unsubscribe: --bKFMwl7rxdP3Qt9n Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Tue, Feb 04, 2025 at 01:12:09AM +0100, Stefano Brivio wrote: > On Tue, 4 Feb 2025 10:55:28 +1100 > David Gibson wrote: >=20 > > On Mon, Feb 03, 2025 at 11:20:03AM +0100, Stefano Brivio wrote: > > > On Mon, 3 Feb 2025 20:26:15 +1100 > > > David Gibson wrote: > > > =20 > > > > +/* Stages for version 1 */ > > > > +static const struct migrate_stage stages_v1[] =3D { > > > > + { > > > > + .name =3D "flow pre", > > > > + .source =3D flow_migrate_source_pre, > > > > + .target =3D NULL, > > > > + }, > > > > + DATA_STAGE(flow_first_free), > > > > + DATA_STAGE(flowtab), > > > > + DATA_STAGE(flow_hashtab), > > > > + DATA_STAGE(g_hash_secret), =20 > > >=20 > > > ...so this one for g_hash_secret (which is the abomination I wanted > > > to drop) would eventually turn into a function? =20 > >=20 > > Yes. > >=20 > > > It looks neat, I'm just not sure if we'll really have "data stages" > > > after I change the approach to only transfer the data we need as you > > > suggested. =20 > >=20 > > I agree, that may well be the case, but we can just drop the macro and > > helepr functions then. > >=20 > > > Is that part of your pending queue by the way, or should I go ahead w= ith > > > it? =20 > >=20 > > Is which part of my pending queue? g_hash_secret as a function? No, > > I've thought of it, but I haven't written it yet. >=20 > No, I meant: "transfer the data we need". No, I haven't begun actually writing it. > > > > [...] > > > > > > > > /** > > > > - * struct migrate_data - Data sections for given source version > > > > - * @v: Source version this applies to, host order > > > > - * @sections: Array of data sections, NULL-terminated > > > > + * migrate_cb_t - Callback function to implement one migration sta= ge > > > > */ > > > > -struct migrate_data { > > > > - uint32_t v; > > > > - struct iovec *sections; > > > > -}; > > > > +typedef int (*migrate_cb_t)(struct ctx *c, struct migrate_meta *m, > > > > + const struct migrate_stage *stage, int fd); =20 > > >=20 > > > typedef is really annoying, we already have a flow_sidx which kind of > > > made sense, but this has really no advantage over something like: =20 > >=20 > > Eh, I guess. I find the extra . or -> a little annoying, but we can > > do this if you'd prefer. >=20 > Well, I find not finding things because of the typedef quite annoying. >=20 > Actually, we don't even need a struct if you prefer (I actually do, but > I know not everybody finds the syntax for function pointers convenient). >=20 > I'm re-posting this squashed onto previous patches but it would be nice > if you could re-post a version of the whole thing without the typedef. Ok. --=20 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 --bKFMwl7rxdP3Qt9n Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQIzBAEBCAAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmehizkACgkQzQJF27ox 2GfN3BAAiQeWe7myx+24paZ/79HFV94lAxm1txPT96unioUbyVX3VwHdsUxZnX9H 2Z5shMgd4BxZom1A8vZ28N7QAoxQ/UWDouzMIz73F/I+a/91HU8ilfTgucg2wnGz aHc2MbMH9liZo5sZISFOhSjBDrT/OAffnvB7CQ1hKD7OcPui5SLdRc55/M2GTXcd eHCQRkcKRRLNRsN7jbVpc8aU0UU1quyvftd+JI2W5C1naEWK7ZT9C8M/iFxLTb3A tONJV5tLp96BaH+kW7vJJgoqpZtZUuoGm+6EwXrx5WUjfdovYHBVo8r3WmfwnEK2 3GU7Q3E8ThY0y40CvsuMB5FrtcUl2OIups5g9vYMlkpbJd+Uv4LzC2eCr993qPET b8rhILleZqMmFaXc/eqUfk2AL8jbP1kwQeXlbhSXMILJMYEcTqT/oVcxX/vwxkjm LRXWZ/lqfYtt+Cz7a1w7ymLwRmLe//jW9pOgSN18rdzhLKXgpVibuJQ0sfZj9Vdf W/QdmvBs5AcpErN8paKNxWAM9ukeQA670FMuzXN2EFN52vd2+MGNR024s2VS2MDO eUlbyswalIjs/Q2miCDX0lZy+Fb6h8/416+5XfEvbW3scVftmhMxAM4nMhukZ4g6 NXUeu79QRhuq2fOqkzNx3zHbV2AbdWv3qHrF8m8KTNAkG5D7XOk= =Qbjs -----END PGP SIGNATURE----- --bKFMwl7rxdP3Qt9n--