Mon, Aug 31, 2026 at 01:45:15PM +0200, [email protected] wrote: >On Thu, Aug 27, 2026 at 02:35:16PM +0200, Jiri Pirko wrote: >> Using generic netlink instead of sysfs for this makes a lot of sense, >> but it may be a bit odd to use it outside the networking area. >> I've been struggling with the same in another non-networking use-case >> as well. > >Agreed, and the series shows the friction. The namespace handling is >nominal, and CAP_NET_ADMIN as the mutation gate is another borrowed >part of the model. I went into that in more detail in the reply to >Jason. > >> - One character device per registered instance, not one global family. >> Access control is the file: udev rules, ACLs, an fd passed into >> a container. > >The fd-based access and event model addresses real problems with one >global family and one multicast group. > >The main question is what the CTLV instance would represent. A fabric >can span multiple devices and has its own lifetime. An endpoint can also >be detached from a fabric with fabric-id 0 and continue to exist. A >character device per accelerator would not provide the same global view >as the current family.
CTVL is supposed to be just "transport". So however you use it is up to you. > >Can a CTLV instance represent a multi-device fabric or the global >fabric registry rather than one physical device? Yes, whoever creates the ctlv instance is in charge of the lifecycle. > >> Would this make sense to use for you? > >In principle, yes. I cannot base this series on an out-of-tree pre-RFC, >but the fabric, endpoint, port and peer model is separate from the >current serialization. > >Changing transports would be more than regeneration, so I will read the >draft before saying more. > >Thanks, >Konstantin
