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: <0daa6f37-8c50-4051-873a-4e8cd4e6cc58@kernel.org>
Date: Wed, 14 Feb 2024 13:31:29 -0700
From: David Ahern <dsahern@...nel.org>
To: Jakub Kicinski <kuba@...nel.org>,
 Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: Saeed Mahameed <saeed@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Leon Romanovsky <leonro@...dia.com>, Jason Gunthorpe <jgg@...dia.com>,
 Jiri Pirko <jiri@...dia.com>, Leonid Bloch <lbloch@...dia.com>,
 Itay Avraham <itayavr@...dia.com>, Saeed Mahameed <saeedm@...dia.com>,
 Aron Silverton <aron.silverton@...cle.com>,
 Christoph Hellwig <hch@...radead.org>, andrew.gospodarek@...adcom.com,
 linux-kernel@...r.kernel.org, netdev@...r.kernel.org
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On 2/9/24 10:01 PM, David Ahern wrote:
> Maybe my bigger question is should drivers that can do different
> physical layers, or can operate without a netdev, should they be split
> into different drivers? drivers/misc for the PCI interface, drivers/net
> for ethernet interfaces and its APIs and drivers/infiniband for IB and
> its APIs? Generic capabilities like this debugging interface belong to
> the PCI device since it is generic to the device hence drivers/misc.
> 

I do not recall seeing a response to this line of questions. We are
considering splitting our driver along these lines to upstream it given
the independent nature of the capabilities and need to interact with
different S/W APIs and hence different maintainers. Any reason new
drivers should not be split along these lines?

If the answer is no, then where is the best home for the PCI device
driver piece of it? drivers/misc or drivers/accel or create a new
drivers/multifcn/?

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ