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: Mon, 8 Apr 2024 09:18:46 +0300
From: Leon Romanovsky <leon@...nel.org>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: Jakub Kicinski <kuba@...nel.org>,
	John Fastabend <john.fastabend@...il.com>,
	Jiri Pirko <jiri@...nulli.us>, netdev@...r.kernel.org,
	bhelgaas@...gle.com, linux-pci@...r.kernel.org,
	Alexander Duyck <alexanderduyck@...com>, davem@...emloft.net,
	pabeni@...hat.com
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

On Fri, Apr 05, 2024 at 08:41:11AM -0700, Alexander Duyck wrote:
> On Thu, Apr 4, 2024 at 7:38 PM Jakub Kicinski <kuba@...nel.org> wrote:

<...>

> > > > Technical solution? Maybe if it's not a public device regression rules
> > > > don't apply? Seems fairly reasonable.
> > >
> > > This is a hypothetical. This driver currently isn't changing anything
> > > outside of itself. At this point the driver would only be build tested
> > > by everyone else. They could just not include it in their Kconfig and
> > > then out-of-sight, out-of-mind.
> >
> > Not changing does not mean not depending on existing behavior.
> > Investigating and fixing properly even the hardest regressions in
> > the stack is a bar that Meta can so easily clear. I don't understand
> > why you are arguing.
> 
> I wasn't saying the driver wouldn't be dependent on existing behavior.
> I was saying that it was a hypothetical that Meta would be a "less
> than cooperative user" and demand a revert.  It is also a hypothetical
> that Linus wouldn't just propose a revert of the fbnic driver instead
> of the API for the crime of being a "less than cooperative maintainer"
> and  then give Meta the Nvidia treatment.

It is very easy to be "less than cooperative maintainer" in netdev world.
1. Be vendor.
2. Propose ideas which are different.
3. Report for user-visible regression.
4. Ask for a fix from the patch author or demand a revert according to netdev rules/practice.

And voilà, you are "less than cooperative maintainer".

So in reality, the "hypothetical" is very close to the reality, unless
Meta contribution will be treated as a special case.

Thanks

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ