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

[Jakub Kicinski <kuba@kernel.org>]

On Thu, 04 Apr 2024 14:59:33 -0700 John Fastabend wrote:
> The alternative is much worse someone builds a team of engineers locks
> them up they build some interesting pieces and we never get to see it
> because we tried to block someone from opensourcing their driver?

Opensourcing is just one push to github.
There are guarantees we give to upstream drivers.

> Eventually they need some kernel changes and than we block those too
> because we didn't allow the driver that was the use case? This seems
> wrong to me.

The flip side of the argument is, what if we allow some device we don't
have access to to make changes to the core for its benefit. Owner
reports that some changes broke the kernel for them. Kernel rules,
regression, we have to revert. This is not a hypothetical, "less than
cooperative users" demanding reverts, and "reporting us to Linus"
is a reality :(

Technical solution? Maybe if it's not a public device regression rules
don't apply? Seems fairly reasonable.

> Anyways we have zero ways to enforce such a policy. Have vendors
> ship a NIC to somebody with the v0 of the patch set? Attach a picture? 

GenAI world, pictures mean nothing :) We do have a CI in netdev, which
is all ready to ingest external results, and a (currently tiny amount?)
of test for NICs. Prove that you care about the device by running the
upstream tests and reporting results? Seems fairly reasonable.

> Even if vendor X claims they will have a product in N months and
> than only sells it to qualified customers what to do we do then.
> Driver author could even believe the hardware will be available
> when they post the driver, but business may change out of hands
> of the developer.
> 
> I'm 100% on letting this through assuming Alex is on top of feedback
> and the code is good.

I'd strongly prefer if we detach our trust and respect for Alex
from whatever precedent we make here. I can't stress this enough.
IDK if I'm exaggerating or it's hard to appreciate the challenges 
of maintainership without living it, but I really don't like being
accused of playing favorites or big companies buying their way in :(

> I think any other policy would be very ugly to enforce, prove, and
> even understand. Obviously code and architecture debates I'm all for.
> Ensuring we have a trusted, experienced person signed up to review
> code, address feedback, fix whatever syzbot finds and so on is also a
> must I think. I'm sure Alex will take care of it.

"Whatever syzbot finds" may be slightly moot for a private device ;)
but otherwise 100%! These are exactly the kind of points I think we
should enumerate. I started writing a list of expectations a while back:

Documentation/maintainer/feature-and-driver-maintainers.rst

I think we just need something like this, maybe just a step up, for
non-public devices..