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]

Message-ID: <6615adbde1430_249cf52944@willemb.c.googlers.com.notmuch>
Date: Tue, 09 Apr 2024 17:06:05 -0400
From: Willem de Bruijn <willemdebruijn.kernel@...il.com>
To: Jakub Kicinski <kuba@...nel.org>, 
 pabeni@...hat.com, 
 John Fastabend <john.fastabend@...il.com>, 
 Alexander Lobakin <aleksander.lobakin@...el.com>, 
 Florian Fainelli <f.fainelli@...il.com>, 
 Andrew Lunn <andrew@...n.ch>, 
 Daniel Borkmann <daniel@...earbox.net>, 
 Edward Cree <ecree.xilinx@...il.com>
Cc: Alexander Duyck <alexander.duyck@...il.com>, 
 netdev@...r.kernel.org, 
 bhelgaas@...gle.com, 
 linux-pci@...r.kernel.org, 
 Alexander Duyck <alexanderduyck@...com>, 
 Willem de Bruijn <willemdebruijn.kernel@...il.com>
Subject: Re: [net-next PATCH 00/15] eth: fbnic: Add network driver for Meta
 Platforms Host Network Interface

Jakub Kicinski wrote:
> On Wed, 03 Apr 2024 13:08:24 -0700 Alexander Duyck wrote:
> > This patch set includes the necessary patches to enable basic Tx and Rx
> > over the Meta Platforms Host Network Interface. To do this we introduce a
> > new driver and driver and directories in the form of
> > "drivers/net/ethernet/meta/fbnic".
> 
> Let me try to restate some takeaways and ask for further clarification
> on the main question...
> 
> First, I think there's broad support for merging the driver itself.
> 
> IIUC there is also broad support to raise the expectations from
> maintainers of drivers for private devices, specifically that they will:
>  - receive weaker "no regression" guarantees
>  - help with refactoring / adapting their drivers more actively
>  - not get upset when we delete those drivers if they stop participating
> 
> If you think that the drivers should be merged *without* setting these
> expectations, please speak up.
> 
> Nobody picked me up on the suggestion to use the CI as a proactive
> check whether the maintainer / owner is still paying attention, 
> but okay :(
> 
> 
> What is less clear to me is what do we do about uAPI / core changes.
> Of those who touched on the subject - few people seem to be curious /
> welcoming to any reasonable features coming out for private devices
> (John, Olek, Florian)? Others are more cautious focusing on blast
> radius and referring to the "two driver rule" (Daniel, Paolo)?
> Whether that means outright ban on touching common code or uAPI
> in ways which aren't exercised by commercial NICs, is unclear. 
> Andrew and Ed did not address the question directly AFAICT.
> 
> Is my reading correct? Does anyone have an opinion on whether we should
> try to dig more into this question prior to merging the driver, and
> set some ground rules? Or proceed and learn by doing?

Thanks for summarizing. That was my reading too

Two distict questions

1. whether a standard driver is as admissible if the device is not
   available on the open market.

2. whether new device features can be supported without at least
   two available devices supporting it.

FWIW, +1 for 1 from me. Any serious device that exists in quantity
and is properly maintained should be in-tree.

In terms of trusting Meta, it is less about karma, but an indication
of these two requirements when the driver first appears. We would not
want to merge vaporware drivers from unknown sources or university
research projects.

2 is out of scope for this series. But I would always want to hear
about potential new features that an organization finds valuable
enough to implement. Rather than a blanket rule against them.