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: <20240409135142.692ed5d9@kernel.org>
Date: Tue, 9 Apr 2024 13:51:42 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: 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

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?