On Wed, Mar 05, 2025 at 07:21:54PM -0400, 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. > > 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. Yes, it can be structured like you proposed too or/and combined with my idea https://lore.kernel.org/netdev/20250303150015.GA1926949@unreal/ The most important part is that it needs to be group of maintainers. > > 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? I like Saeed's proposal "drivers/aux/", it is more short and catchy. Thanks > > Jason >
