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: <CAKgT0UepNfYJN73J9LRWwAGqQ7YPwQUNTXff3PTN26DpwWix8Q@mail.gmail.com>
Date: Wed, 10 Apr 2024 11:01:44 -0700
From: Alexander Duyck <alexander.duyck@...il.com>
To: Jakub Kicinski <kuba@...nel.org>
Cc: Florian Fainelli <f.fainelli@...il.com>, Jiri Pirko <jiri@...nulli.us>, pabeni@...hat.com, 
	John Fastabend <john.fastabend@...il.com>, Alexander Lobakin <aleksander.lobakin@...el.com>, 
	Andrew Lunn <andrew@...n.ch>, Daniel Borkmann <daniel@...earbox.net>, 
	Edward Cree <ecree.xilinx@...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, Apr 10, 2024 at 10:56 AM Jakub Kicinski <kuba@...nel.org> wrote:
>
> On Wed, 10 Apr 2024 10:39:11 -0700 Florian Fainelli wrote:
> > > 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.
> >
> > Do we really need that categorization at the directory/filesystem level?
> > cannot we just document it clearly in the Kconfig help text and under
> > Documentation/networking/?
>
> From the reviewer perspective I think we will just remember.
> If some newcomer tries to do refactoring they may benefit from seeing
> this is a special device and more help is offered. Dunno if a newcomer
> would look at the right docs.
>
> Whether it's more "paperwork" than we'll actually gain, I have no idea.
> I may not be the best person to comment.

Are we going to go through and retro-actively move some of the drivers
that are already there that are exclusive to specific companies? That
is the bigger issue as I see it. It has already been brought up that
idpf is exclusive. In addition several other people have reached out
to me about other devices that are exclusive to other organizations.

I don't see any value in it as it would just encourage people to lie
in order to avoid being put in what would essentially become a
blacklisted directory.

If we are going to be trying to come up with some special status maybe
it makes sense to have some status in the MAINTAINERS file that would
indicate that this driver is exclusive to some organization and not
publicly available so any maintenance would have to be proprietary.