Re: [PATCH 01/15] netlink: specs: Introduce multi-message blobs for SPDM

Jakub Kicinski <[email protected]> Mon, 3 Aug 2026 09:35:56 -0700
Newsgroups dev.linux.lists.driver-core,dev.linux.lists.linux-coco,org.kernel.vger.linux-pci
Message-ID <[email protected]>
On Sun, 2 Aug 2026 17:58:06 +0000 Ankit Agrawal wrote:
> > I don't like this, sorry. You need to come up with something outside
> > of netlink or more netlink-y. =20
>=20
> Hi Jakub, picking this up and continuing on with the Dan's work.
>=20
> In an earlier discussion [1], two options were mentioned.
>=20
> > Alright, so to make this more Netlink-y you can either:
> =C2=A0=C2=A0>=C2=A0 - delete the F_MULTI and replicate other attrs in eac=
h message and
> =C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0 add an offset attr; this will make each m=
essage in the dump more
> =C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0 standalone.
> =C2=A0=C2=A0>=C2=A0 - keep the F_MULTI but object_val has to be a multi-a=
ttr, and then
> =C2=A0=C2=A0>=C2=A0=C2=A0=C2=A0 we have to teach YNL to correctly append =
the attrs. =20
>=20
> So I'll update to the first option of standalone messages with an offset =
attribute.
> i.e. every dump message with a new offset for the chunk it carries and wi=
th
> reassembly left to the consumer. I suppose that aligns with your preferen=
ce?
>=20
> [1] https://lore.kernel.org/all/[email protected]/

Yes, cleanly building the blob in netlink is going to be tough.
First option would be uncontroversial from Netlink PoV, AFAICT.
But also please spend a bit of time on trying to come up with
a better way of moving the blobs.