From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: passt.top; dmarc=pass (p=none dis=none) header.from=redhat.com Authentication-Results: passt.top; dkim=pass (1024-bit key; unprotected) header.d=redhat.com header.i=@redhat.com header.a=rsa-sha256 header.s=mimecast20190719 header.b=bYKg4P6e; dkim-atps=neutral Received: from us-smtp-delivery-124.mimecast.com (us-smtp-delivery-124.mimecast.com [170.10.133.124]) by passt.top (Postfix) with ESMTPS id A82AE5A0271 for ; Tue, 04 Feb 2025 01:12:17 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=redhat.com; s=mimecast20190719; t=1738627936; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=pzUJz4JP78+MiTUsVldqUhoQVL75s4geKTsqNRWgkz0=; b=bYKg4P6e5mWW/BzD2m6um9CMLiGoQrppENGJsHJJ+aVyGpxJIQXY3E2gBgiXEUn/8WHxmR hZqTUPLGrZ0NnlyG/gJT3z8/iRKYw7I37jnYd9ZPUiGELvzeYoF3re4X4h/ZQOyKrtyKX9 /t4J4AhD//4HGIowtxjm97M8O8VmjI4= Received: from mail-wr1-f69.google.com (mail-wr1-f69.google.com [209.85.221.69]) by relay.mimecast.com with ESMTP with STARTTLS (version=TLSv1.3, cipher=TLS_AES_256_GCM_SHA384) id us-mta-398-Z11_m-cCMDGLrpvtWSuY_A-1; Mon, 03 Feb 2025 19:12:14 -0500 X-MC-Unique: Z11_m-cCMDGLrpvtWSuY_A-1 X-Mimecast-MFC-AGG-ID: Z11_m-cCMDGLrpvtWSuY_A Received: by mail-wr1-f69.google.com with SMTP id ffacd0b85a97d-38da7135a19so70251f8f.2 for ; Mon, 03 Feb 2025 16:12:14 -0800 (PST) X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1738627932; x=1739232732; h=content-transfer-encoding:mime-version:organization:references :in-reply-to:message-id:subject:cc:to:from:date:x-gm-message-state :from:to:cc:subject:date:message-id:reply-to; bh=pzUJz4JP78+MiTUsVldqUhoQVL75s4geKTsqNRWgkz0=; b=jagfOiw3V9cnQ5PIH5w0Fggc3iCUBMUv8mj7OZvy1453sgEBHQX/McyMmLw/YSs2CG TWo0B4DDo+KM/wkuNYe1lrEyNSbbQfKo5FAiIvrJTQI9kg2dT3ZIKSvVvYTYYWZZ4CDJ U8CAA/GGjAQNArAkRboW6iyDcpXz36LRAe9TTa9NFho4ZrI/GPUoPBZv3nEBQwPs5Xd3 uz8GEcVQwOx+25objSCv8TbcsqCHeXffnLnhXEt0nN3UFwr6r9j8j83rzaCi7kOb10aK q4Z77F0ithGV06Igb59wKKcxZOGjqcjyW1wB57Mk1G3lkHs8NgOHYgbYpsoyJSA7vryu WzhQ== X-Gm-Message-State: AOJu0Yx+/DV1X0/GdexCAlOUJQFVIbjpnGJb6oSOnLd8MRqmPeL2txhP MiZsx5OvATyD367Jpb4gPgKTG8BtUvKqKOlOP6dhQNPl6axQs5efaREZrBf1gEEwMOgRJmC6L2Z BhJTJcH15NkKMXmMDirg+jxwByAegmxSAtpjxNTEQhDGMDn2AXFHHQBJQtw== X-Gm-Gg: ASbGncupIeLdSjiAr6Hdwd+hK7ahM3PaqVbodyTQQLUd1/95wZIL0Lxln1iu/i+QqI2 TOrlBY6MFVh75CAsYCewAa0ylzerwd7zCTK0xpc2kxjpa19407YupnP1XnF5mt/fCtqARlUE7M8 Gk7mGivSHGyPMuA1gjH8cns4u8mX7nInoumZOZE/N4WqLb8djVeZWY7m9u4fLG/ejQTwn4ML/HL wEvsC1xOL0IRru2hag8wlHKFv49cYbRXQq62cW4J8Nh5kL8bTvt3u6XLFwhtegL/e5q66BAOrrp rzURIRk8oXzk9bWUhif5YskQDlJhP38SzA== X-Received: by 2002:a5d:59a6:0:b0:385:df43:223c with SMTP id ffacd0b85a97d-38c5194b798mr20700163f8f.13.1738627932676; Mon, 03 Feb 2025 16:12:12 -0800 (PST) X-Google-Smtp-Source: AGHT+IFilHhu+6rBQdUunppzVRjW0cRSvv1I3UOcTMbKigZdWlahf8ALusIqFsVqOJgQTEjBTgAudQ== X-Received: by 2002:a5d:59a6:0:b0:385:df43:223c with SMTP id ffacd0b85a97d-38c5194b798mr20700151f8f.13.1738627932336; Mon, 03 Feb 2025 16:12:12 -0800 (PST) Received: from maya.myfinge.rs (ifcgrfdd.trafficplex.cloud. [176.103.220.4]) by smtp.gmail.com with ESMTPSA id 5b1f17b1804b1-438dcc13146sm204357115e9.4.2025.02.03.16.12.10 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 03 Feb 2025 16:12:10 -0800 (PST) Date: Tue, 4 Feb 2025 01:12:09 +0100 From: Stefano Brivio To: David Gibson Subject: Re: [PATCH 6/6] migrate: Make migration handlers simpler and more flexible Message-ID: <20250204011209.7a28decf@elisabeth> In-Reply-To: References: <20250203092615.500163-1-david@gibson.dropbear.id.au> <20250203092615.500163-7-david@gibson.dropbear.id.au> <20250203112003.1bcc7acd@elisabeth> Organization: Red Hat X-Mailer: Claws Mail 4.2.0 (GTK 3.24.41; x86_64-pc-linux-gnu) MIME-Version: 1.0 X-Mimecast-Spam-Score: 0 X-Mimecast-MFC-PROC-ID: -zwXVnGc9j16wFQyBrZsp47QCqUvBwSgfvnAuHitYGE_1738627933 X-Mimecast-Originator: redhat.com Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit Message-ID-Hash: W7MMQA53AUDAF6GN4EMLYQVXD5A4JAJO X-Message-ID-Hash: W7MMQA53AUDAF6GN4EMLYQVXD5A4JAJO X-MailFrom: sbrivio@redhat.com 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: On Tue, 4 Feb 2025 10:55:28 +1100 David Gibson wrote: > 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: > > > > > +/* Stages for version 1 */ > > > +static const struct migrate_stage stages_v1[] = { > > > + { > > > + .name = "flow pre", > > > + .source = flow_migrate_source_pre, > > > + .target = NULL, > > > + }, > > > + DATA_STAGE(flow_first_free), > > > + DATA_STAGE(flowtab), > > > + DATA_STAGE(flow_hashtab), > > > + DATA_STAGE(g_hash_secret), > > > > ...so this one for g_hash_secret (which is the abomination I wanted > > to drop) would eventually turn into a function? > > Yes. > > > 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. > > I agree, that may well be the case, but we can just drop the macro and > helepr functions then. > > > Is that part of your pending queue by the way, or should I go ahead with > > it? > > 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. No, I meant: "transfer the data we need". > > > [...] > > > > > > /** > > > - * 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 stage > > > */ > > > -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); > > > > typedef is really annoying, we already have a flow_sidx which kind of > > made sense, but this has really no advantage over something like: > > Eh, I guess. I find the extra . or -> a little annoying, but we can > do this if you'd prefer. Well, I find not finding things because of the typedef quite annoying. 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). 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. -- Stefano