Re: [PATCH RFC 13/20] Documentation: ctlv: Describe how to write a family

[Jason Gunthorpe]

On Thu, Oct 22, 2026 at 10:22:55AM +0200, Jiri Pirko wrote:

> >But it does work well here, and matches what rdma and fwctl did as
> >well. So maybe iommufd is weird.
> 
> Well, one CTLV chardev is always backed by one device. I think this 1:1
> mapping is clear in the device model. Iommufd indeed looks weird in this
> matter.

iommufd doesn't do 1:1 with a device..

It is more like netlink where it talks to all the devices in the
system concurrently.

> >> Depends on the user/subsystem. Either families_dump op could be used of
> >> udev uvevents that also carry family inheritance chain:
> >>     CTLV_FAMILY=ctlv-attestation-tdx
> >>     CTLV_COMPATIBLE_0=ctlv
> >>     CTLV_COMPATIBLE_1=ctlv-attestation
> >>     CTLV_COMPATIBLE_2=ctlv-attestation-tdx
> >>     CTLV_COMPATIBLE_N=3
> >
> >I wouldn't try to link it to udev either, by the time some userspace
> >uses the cdev the udev information is gone, and may be unreachable
> >from inside a container or similar..
> 
> This just gives possibility for udev to work properly. Depends on
> the user/usecase if it's going to be used or not. Not sure what you mean
> by "udev information is gone". Udev might use these uevent info to do
> aliases, similar to dev/disk/by-*

I don't know if you can encode N compatible strings into a file name.

And in a container or something you can't get the uevent, so no client
software could rely on this information.

Jason