netdev - Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta Platforms Host Network Interface

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 08:26:33 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Leon Romanovsky <leon@...nel.org>
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 Sun, Apr 7, 2024 at 11:18 PM Leon Romanovsky <leon@...nel.org> wrote:
>
> 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

How many cases of that have we had in the past? I'm honestly curious
as I don't actually have any reference.

Also as far as item 3 isn't hard for it to be a "user-visible"
regression if there are no users outside of the vendor that is
maintaining the driver to report it? Again I am assuming that the same
rules wouldn't necessarily apply in the vendor/consumer being one
entity case.

Also from my past experience the community doesn't give a damn about
1. It is only if 3 is being reported by actual users that somebody
would care. The fact is if vendors held that much power they would
have run roughshod over the community long ago as I know there are
vendors who love to provide one-off projects outside of the kernel and
usually have to work to get things into the upstream later and no
amount of complaining about "the users" will get their code accepted.
The users may complain but it is the vendors fault for that so the
community doesn't have to take action.