Re: [PATCH v5 0/8] Introduce fwctl subystem

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



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.





[Index of Archives]     [Linux USB Devel]     [Video for Linux]     [Linux Audio Users]     [Photo]     [Yosemite News]     [Yosemite Photos]     [Linux Kernel]     [Linux SCSI]     [XFree86]

  Powered by Linux