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: <20240415101101.3dd207c4@kernel.org>
Date: Mon, 15 Apr 2024 10:11:01 -0700
From: Jakub Kicinski <kuba@...nel.org>
To: Alexander Duyck <alexander.duyck@...il.com>
Cc: Yunsheng Lin <linyunsheng@...wei.com>, netdev@...r.kernel.org, Alexander
 Duyck <alexanderduyck@...com>, davem@...emloft.net, pabeni@...hat.com
Subject: Re: [net-next PATCH 13/15] eth: fbnic: add basic Rx handling

On Mon, 15 Apr 2024 08:03:38 -0700 Alexander Duyck wrote:
> > > The advantage of being a purpose built driver is that we aren't
> > > running on any architectures where the PAGE_SIZE > 4K. If it came to  
> >
> > I am not sure if 'being a purpose built driver' argument is strong enough
> > here, at least the Kconfig does not seems to be suggesting it is a purpose
> > built driver, perhaps add a 'depend on' to suggest that?  
> 
> I'm not sure if you have been following the other threads. One of the
> general thoughts of pushback against this driver was that Meta is
> currently the only company that will have possession of this NIC. As
> such Meta will be deciding what systems it goes into and as a result
> of that we aren't likely to be running it on systems with 64K pages.

Didn't take long for this argument to float to the surface..

We tried to write some rules with Paolo but haven't published them, yet.
Here is one that may be relevant:

  3. External contributions
  -------------------------

  Owners of drivers for private devices must not exhibit a stronger
  sense of ownership or push back on accepting code changes from
  members of the community. 3rd party contributions should be evaluated
  and eventually accepted, or challenged only on technical arguments
  based on the code itself. In particular, the argument that the owner
  is the only user and therefore knows best should not be used.

Not exactly a contribution, but we predicted the "we know best"
tone of the argument :(

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ