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=202606 header.b=BRuatBrg; dkim-atps=neutral Received: from mail.ozlabs.org (gandalf.ozlabs.org [150.107.74.76]) by passt.top (Postfix) with ESMTPS id A377B5A0271 for ; Mon, 15 Jun 2026 04:13:21 +0200 (CEST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gibson.dropbear.id.au; s=202606; t=1781489597; bh=GBo0/c5AjcILz5LMjuY608RRLguF6HglCdc5tR2+gDU=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=BRuatBrgf65jr6GSXOi5Y265j35TQBvhnrBlNFHHcbOTqWeCTF5kUXHPpgFNQgabm tlRnUiY9qYqdLNI8EZDz9pyjQiWKumAbRLJNaLP3pdo2QE2iWeb+CzkePEIkM7y/UR p2q7Rgr7d5LSJUmXB+FWKSxPoBUbRXghLZ+UEZRHEBzZuftm711jN8Esc/PFJRP0aG Rlvt2WaSzZ9NyJ2g2QBtKn5PFLXAHYK1ejlS9AyMgEfQXrji/NSpitntbYV3chjQHE bHBrGDNAsWyatfpY+0EbUzPQ64HSxCgrAMwCiY/pT6e69AifDM77KSt4CYPsjKyNIi TLwazTI3wF1pQ== Received: by gandalf.ozlabs.org (Postfix, from userid 1007) id 4gdtvK6w9nz4wQf; Mon, 15 Jun 2026 12:13:17 +1000 (AEST) Date: Mon, 15 Jun 2026 12:09:42 +1000 From: David Gibson To: Stefano Brivio Subject: Re: [PATCH v3 3/6] dhcp: Add option type table and value parser Message-ID: References: <20260601073758.1571317-1-anskuma@redhat.com> <20260601073758.1571317-4-anskuma@redhat.com> <20260612010436.6b25300f@elisabeth> MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="+5J6AyxzGx8w70li" Content-Disposition: inline In-Reply-To: <20260612010436.6b25300f@elisabeth> Message-ID-Hash: GOQEBBBOTDBHP4BTIUU4CLNANNJYHXOU X-Message-ID-Hash: GOQEBBBOTDBHP4BTIUU4CLNANNJYHXOU 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: Anshu Kumari , passt-dev@passt.top, jmaloy@redhat.com, lvivier@redhat.com 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: --+5J6AyxzGx8w70li Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable On Fri, Jun 12, 2026 at 01:04:37AM +0200, Stefano Brivio wrote: > On Tue, 2 Jun 2026 12:23:47 +1000 > David Gibson wrote: >=20 > > On Mon, Jun 01, 2026 at 01:07:53PM +0530, Anshu Kumari wrote: > > > > > [...] > > > > > > +/** > > > + * dhcp_opt_types - Maps option code to RFC 2132 value type, indexed= by code > > > + */ > > > +static const enum dhcp_opt_type dhcp_opt_types[256] =3D { > > > + [1] =3D DHCP_OPT_IPV4, /* Subnet Mask */ > > > + [2] =3D DHCP_OPT_INT32, /* Time Offset */ > > > + [3] =3D DHCP_OPT_IPV4_LIST, /* Router */ =20 > >=20 > > I'm still a bit unsure if we want to allow user modification of the > > options, like this one, which we already manage ourselves. >=20 > I think we don't lose any functionality if we allow users to overwrite > them, and we might gain some: for example one might want to directly > set a specific default route in the target network namespace, in pasta, > but change it as a DHCP client runs. >=20 > Not that I see any point in doing that, but it's harmless, so why not. > Maybe even just for testing, go figure. Fair point, I concur. > > > [...] > > > > > > @@ -61,7 +227,15 @@ int dhcp_add_option(struct ctx *c, uint8_t code, = const char *val_str) > > > c->custom_opts_count++; > > > } > > > =20 > > > + ret =3D dhcp_opt_parse(code, val_str, > > > + c->custom_opts[idx].val, > > > + sizeof(c->custom_opts[0].val)); =20 > >=20 > > Now that this parsing and adding code is all in dhcp.c, could we parse > > the options directly into the existing opts[] global, rather than > > requiring both the string and parsed forms in c->custom_opts? >=20 > I see one downside with that: the day we add the possibility for > pesto(1) to set and read out options, we would need to add an > implementation to decode them back, which could be rather complicated > if you think of stuff such as "compressed" (yes, that madness) domain > names. Sorry, let me clarify. I'm not suggesting we remove the string version of the value, for exactly that reason (along with making debugging messages easier). However, at the moment I think we end up with *two* copies of the parsed binary value: one in c->custom_opts[].val, and another in the opts[].s global within dhcp.c. I'm hoping we can remove one of them; the one in custom_opts seeming like the easier one. --=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 --+5J6AyxzGx8w70li Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iQIzBAEBCgAdFiEEO+dNsU4E3yXUXRK2zQJF27ox2GcFAmovXuUACgkQzQJF27ox 2GdQbRAAqVvGyeN9VElK52GSoX8brR0z3CsQCy5WIwodwCdq6TtS0lCjZCWcdnmo ONSCEi4HGj8UixZNs6bOEtjN65jizRszRqTt+E0Xnfi7Tf1TgtvxL85o0ev0COBd JIlUczU2arka3fLkLuIRhAJjse4p8LwgcwAXC+Sp33EfItHRoM8KRb5aARhhPSFP diGXPD/penlpPj60jW6Ex4s+nBd5HYuxAYfBebUtKm1lE2X9qMnu3AUzX8PQfE0J SvDddRSrIqjJFuJF0ipRYLGa7XTqLvaHhHcehJMjMPiA7ead+ppF46afDgC9JA6G Ml0hx/1D3bF30/liJpQ5GDwwxeFugtc++UUsWaLmm3vqjJtdOHZfyVPhvpyxuc5S oy4sCeL0TAMqqlSKGoTveThdc6nG5Vi9KY1juhHhGTzC2ohbnUGNAzdL1Pykfdbn 9tFZDlLBWg52zgWa62O9rL3UiLV1MepQi6rCn5u5/9vtkcOECXTCuYr/hMXZ1TPM 280XrPzOlzI3FvQ9KpkcAk2/yADgsFWIJXn7R5dVhwCooIpn4YdcDyuYMdsZtoQQ GbVXVSlzxNlCj4KMiCHxEj43qhPMmXNfeY+YbCWdoc/jUNe5WyPIkJr26avz230g L172VADGdnfr1KmvdYey+Ue4n/u3iwp2xbv3RZnoNNi/NCAzZnI= =tbkd -----END PGP SIGNATURE----- --+5J6AyxzGx8w70li--