Re: [PATCH v2 08/19] PCI/TSM: Add "evidence" support

[Jakub Kicinski <kuba@kernel.org>]

On Mon, 16 Mar 2026 18:45:24 -0700 Dan Williams wrote:
> Jakub Kicinski wrote:
> > On Mon,  2 Mar 2026 16:01:56 -0800 Dan Williams wrote:  
> > > The implementation adheres to the guideline from:
> > > Documentation/userspace-api/netlink/genetlink-legacy.rst
> > > 
> > >     New Netlink families should never respond to a DO operation with
> > >     multiple replies, with ``NLM_F_MULTI`` set. Use a filtered dump
> > >     instead.  
> > 
> > My understanding of F_MULTI is that deserializer is supposed to
> > continue deserializing into current object. IOW if we have:
> > 
> > struct does_this {
> > 	int really;
> > 	int have_to;
> > 	int be_netlink;
> > };  
> 
> Heh, sensing a subtle message here...

One learns to optimize for conserving one's own attention wherever
possible :>

> > The main strength of Netlink is "do" commands with multiple optional
> > attrs.  
> 
> Yes, that is attractive and saves a pile of bug prone ioctl handling.
> 
> The gap I need to fill first though is a uAPI that allows for large
> blobs to be fetched after being regenerated / reformatted besed on some
> input attributes.
> 
> "Multi message netlink attributes" while inventive, feels less awkward
> and more future proof than a sysfs binary attribute scheme to do the
> same.

Alright, so to make this more Netlink-y you can either:
 - delete the F_MULTI and replicate other attrs in each message and 
   add an offset attr; this will make each message in the dump more
   standalone. 
 - keep the F_MULTI but object_val has to be a multi-attr, and then 
   we have to teach YNL to correctly append the attrs.

Former is definitely less work. Latter could end up being cleaner
but there are some unknowns so hard to tell for sure; more plumbing.