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. > > Driver maintainers with the most commits per cycle does the PR or > something like that. > > There is no subsystem or cross-driver entanglement so there is no real > need for gatekeeping. > > It would be a good opportunity to help more people engage with the > kernel process and learn the full maintainer flow. > >> It should be something that is tightly coupled with aux, currently >> aux is under drivers/base/auxiliary.c I think it should move to >> drivers/aux/auxiliary.c and device drivers should implement their >> own aux buses, WH access APIs and probing/init logic under that >> directory e.g: drivers/aux/mlx5/.. > > That makes sense to me. I would expect everything in this collection > to be PCI drivers spawing aux devices. > > drivers/aux_core/ or something like that, perhaps? > drivers/aux_core works for me; removes the 'pci' assumption and makes it clear the real attribute here is use of the aux bus with subsystem specific devices. I am still not clear on how such a branch will work - e.g. We will want multi-vendor review, not just merge the PR and go.
