Subject: Re: [PATCH V4 0/5] mlx5 ConnectX control misc driver

From: Jason Gunthorpe <[email-masked]>
Date: Thu, 4 Apr 2024 15:33:05 -0300

On Thu, Apr 04, 2024 at 06:35:04PM +0100, Edward Cree wrote:
> [ Again, I had better disassociate my employer from the vitriol below,
>   for which I alone am responsible. ]
> 
> On 02/04/2024 19:40, Jason Gunthorpe wrote:
> > Uh no. Alot of this configuration stuff is to serve niche customer
> > interests where the customers have no interest in publishing and
> > commonizing their method of operating because it would give away their
> > own operator secrets. The vendor's created it because their big
> > customers demanded it.
> > 
> > eg there are configurables in mlx5 that exist *soley* to accomodate
> > certain customer's pre-existing SW.
> 
> So it's a single-user hack, why do you want support for it in upstream?
> Oh right, because you want to be able to ship single-user hacks to all
>  your customers while still getting the _cachet_ of being An Intree
>  Driver with the implied engineering benefits of open source — despite
>  the actual feature implementations being obscured in firmware that's
>  not subject to the review process and thus doesn't actually carry
>  those benefits.

Uh no, mlx5 already has an excellent in-tree driver, thank you very
much. The configuration is not changing the driver, it is changing the
device.

Consider, I can ship unique devices pre-configured for each site's
special needs. They still work with the same inbox driver.

In fact that happens already for certain large customers. It is why
Jakub recently pointed out that Meta doesn't need any
provisioning/mlx5ctl/misc driver. They just buy different devices than
everyone else.

So, it is really some kind of extremism to say that allowing users to
configure the device in their own system in a booted Linux OS instead
of in the factory looses the "implied engineering benefits of open
source".

Further it is really rude and inappropriate to say that some customers
should not be able to enjoy intree drivers because of your aesthetic
opinion of hacks in a device's design.

> > There are something like 600-800 configurables in mlx5
> 
> So because your engineers can't design clean, orthogonal APIs for
>  toffee, you should be allowed to bypass review?  Sorry, but no.

Overreach. The job of the kernel maintainer is to review the driver
software, not the device design.

> > Where is the screaming?  Where has keeping blessed support out of
> > the kernel got us?
> 
> Well, clearly *someone* wants you to supply them an in-tree driver,
>  else you wouldn't be trying to upstream this.  

We already have an intree driver for this access, it is built into
sysfs. Tooling exists everything is deployed, people are happy.

If you had read the thread to understand the issue, you'd know this is
because the distros have turned on module signing, secure boot and
kernel lock down.

This disables the ability to have an OOT driver, it disables the
existing sysfs scheme and it forces everything to be in Linus's tree
or it does not exist. It effectively breaks the long existing
ecosystem in this space.

Arguing that keeping things working as they have been working for the
last 10 years is somehow going to wreck opensource or whatever is
absurd.

Jason