linux-kernel - Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

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]

Date: Tue, 2 Apr 2024 17:32:44 +0100
From: Edward Cree <ecree.xilinx@...il.com>
To: David Ahern <dsahern@...nel.org>, Jakub Kicinski <kuba@...nel.org>
Cc: Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
 Jason Gunthorpe <jgg@...dia.com>, Christoph Hellwig <hch@...radead.org>,
 Saeed Mahameed <saeed@...nel.org>, Arnd Bergmann <arnd@...db.de>,
 Leon Romanovsky <leonro@...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>, linux-kernel@...r.kernel.org,
 "netdev@...r.kernel.org" <netdev@...r.kernel.org>,
 Andy Gospodarek <andrew.gospodarek@...adcom.com>
Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

On 26/03/2024 14:57, David Ahern wrote:
> The proposal is an attempt at a common interface and common tooling to a
> degree but independent of any specific subsystem of which many are
> supported by the device.

[ Let me prefix this by noting that I'm speaking personally here, and
  not representing the position of my employer. ]

You can't have a "common interface" and yet be "independent" of anything
 that could give semantics to that interface.  What you have is a common
 *transport*, used to connect to a *vendor* interface.
If you can't even bring yourself to be honest about that, it's no wonder
 you're getting maintainer pushback.

Do we need to go all the way back to operating systems 101 and point out
 that one of the fundamental jobs of a kernel is to *abstract* the
 hardware, and provide *services* to userspace rather than mere devices?

Frankly, this whole thread reads to me like certain vendors whining that
 they weren't expecting to have to get their new features *reviewed* by
 upstream — possibly they thought devlink params would just get rubber-
 stamped — and now they're finding that the kernel's quality standards
 still apply.
Complaining that devlink params "don't scale" is disingenuous.  Patches
 aren't languishing for want of reviewer resources; it's just that it
 takes *submitter* time and effort to bring them up to the quality level
 that's required, and occasionally the vendor has to (shock! horror!)
 tell the world what one of their magic knobs actually *does*.

If all the configuration of these Complex Devices™ goes through fwctl
 backdoors, where exactly is anyone going to discover the commonalities
 to underlie the generic interfaces of the next generation?  What would
 configuring plain vanilla netdevs be like today if, instead of a set of
 well-defined cross-vendor APIs, ethtool (say) had been a mechanism to
 write arbitrary values to hardware registers on the NIC?
These commonalities are key to allowing a product category to mature.  I
 realise vendors in many cases don't want that to happen, because mature
 products are largely commoditised and thus don't command huge margins;
 but Linux isn't here to serve vendors' interests at the expense of
 users.

On 23/03/2024 01:27, Saeed Mahameed wrote:
> It is obvious to everyone that in the AI era, everyone needs
> customization

It's always possible to argue that the New Thing is qualitatively
 different from anything that went before, that these "multibillion
 gate devices" need to be able to break the rules.
But the truth is, you aren't that special.

-e