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

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <d0e95c47-c812-4aa8-812f-f5d7f6abbbb1@intel.com>
Date: Fri, 14 Mar 2025 11:09:47 -0700
From: Jacob Keller <jacob.e.keller@...el.com>
To: "Nelson, Shannon" <shannon.nelson@....com>, Leon Romanovsky
	<leon@...nel.org>, David Ahern <dsahern@...nel.org>
CC: Jiri Pirko <jiri@...nulli.us>, Jason Gunthorpe <jgg@...dia.com>, "Jakub
 Kicinski" <kuba@...nel.org>, Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
	Andy Gospodarek <andrew.gospodarek@...adcom.com>, Aron Silverton
	<aron.silverton@...cle.com>, Dan Williams <dan.j.williams@...el.com>, "Daniel
 Vetter" <daniel.vetter@...ll.ch>, Dave Jiang <dave.jiang@...el.com>,
	"Christoph Hellwig" <hch@...radead.org>, Itay Avraham <itayavr@...dia.com>,
	Jiri Pirko <jiri@...dia.com>, Jonathan Cameron <Jonathan.Cameron@...wei.com>,
	"Leonid Bloch" <lbloch@...dia.com>, <linux-cxl@...r.kernel.org>,
	<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>, Saeed Mahameed
	<saeedm@...dia.com>, "Sinyuk, Konstantin" <konstantin.sinyuk@...el.com>
Subject: Re: [PATCH v5 0/8] Introduce fwctl subystem



On 3/13/2025 12:59 PM, Nelson, Shannon wrote:
> On 3/13/2025 5:48 AM, Leon Romanovsky wrote:
>> On Thu, Mar 13, 2025 at 01:30:52PM +0100, David Ahern wrote:
> 
> 
>>> So that means 3 different vendors and 3 different devices looking for a
>>> similar auxbus based hierarchy with a core driver not buried within one
>>> of the subsystems.
>>>
>>> I guess at this point we just need to move forward with the proposal and
>>> start sending patches.
>>>
>>> Seems like drivers/core is the consensus for the core driver?
>>
>> Yes, anything that is not aux_core is fine by me.
>>
>> drivers/core or drivers/aux.
> 
> Between the two of these I prefer drivers/core - I don't want to see 
> this tied to aux for the same reasons we don't want it tied to pci or net.
> 
> sln
> 
> 

I'd throw my hat in for drivers/core as well, I think it makes the most
sense and is the most subsystem neutral name. Hopefully any issue with
tooling can be solved relatively easily.