On 3/11/25 2:59 PM, Leon Romanovsky wrote: > On Tue, Mar 11, 2025 at 12:23:19PM +0100, David Ahern wrote: >> On 3/6/25 12:21 AM, Jason Gunthorpe wrote: >>> On Wed, Mar 05, 2025 at 12:41:35PM -0800, Saeed Mahameed wrote: >>> >>>> How do you imagine this driver/core structure should look like? Who >>>> will be the top dir maintainer? >>> >>> I would set something like this up more like DRM. Every driver >>> maintainer gets commit rights, some rules about no uAPIs, or at least >>> other acks before merging uAPI. Use the tree for staging shared >>> branches. >> >> why no uapi? Core driver can have knowledge of h/w resources across all >> use cases. For example, our core driver supports a generid netlink based >> dump (no set operations; get and dump only so maybe that should be the >> restriction?) of all objects regardless of how created -- netdev, ib, >> etc. -- and with much more detail. > > Because, we want to make sure that UAPI will be aligned with relevant > subsystems without any way to bypass them. > > Thanks I hope there will be an open mind on get / dump style introspection apis here. Devices can work support and work within limited subsystem APIs and also allow the dumping of full essential and relevant contexts for a device. More specifically, I do not see netdev APIs ever recognizing RDMA concepts like domains and memory regions. For us, everything is relative to a domain and a region - e.g., whether a queue is created for a netdev device or an IB QP both use the same common internal APIs. I would prefer not to use fwctl for something so basic.
