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: <20240410103531.46437def@kernel.org>
Date: Wed, 10 Apr 2024 10:35:31 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Jiri Pirko <jiri@...nulli.us>
Cc: 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>, 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, 10 Apr 2024 17:12:18 +0200 Jiri Pirko wrote:
> >> For these kind of unused drivers, I think it would be legit to
> >> disallow any internal/external api changes. Just do that for some
> >> normal driver, then benefit from the changes in the unused driver.  
> >
> >Unused is a bit strong, and we didn't put netdevsim in a special
> >directory. Let's see if more such drivers appear and if there
> >are practical uses for the separation for scripts etc?  
> 
> The practical use I see that the reviewer would spot right away is
> someone pushes a feature implemented in this unused driver only.
> Say it would be a clear mark for a driver of lower category.
> For the person doing API change it would be an indication that he
> does not have that cautious to not to break anything in this driver.
> The driver maintainer should be the one to deal with potential issues.

Hm, we currently group by vendor but the fact it's a private device
is probably more important indeed. For example if Google submits
a driver for a private device it may be confusing what's public
cloud (which I think/hope GVE is) and what's fully private.

So we could categorize by the characteristic rather than vendor:

drivers/net/ethernet/${term}/fbnic/

I'm afraid it may be hard for us to agree on an accurate term, tho.
"Unused" sounds.. odd, we don't keep unused code, "private"
sounds like we granted someone special right not took some away,
maybe "exclusive"? Or "besteffort"? Or "staging" :D  IDK.

> With this clear marking and Documentation to describe it, I think I
> would be ok to let this in, FWIW.