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: <66b2ba7150128_c1448294fe@dwillia2-xfh.jf.intel.com.notmuch>
Date: Tue, 6 Aug 2024 17:06:09 -0700
From: Dan Williams <dan.j.williams@...el.com>
To: Jason Gunthorpe <jgg@...dia.com>, James Bottomley
	<James.Bottomley@...senpartnership.com>
CC: Greg KH <gregkh@...uxfoundation.org>, Laurent Pinchart
	<laurent.pinchart@...asonboard.com>, Dan Williams <dan.j.williams@...el.com>,
	<ksummit@...ts.linux.dev>, <linux-cxl@...r.kernel.org>,
	<linux-rdma@...r.kernel.org>, <netdev@...r.kernel.org>
Subject: Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

Jason Gunthorpe wrote:
> On Wed, Jul 31, 2024 at 08:33:36AM -0400, James Bottomley wrote:
> 
> > For the specific issue of discussing fwctl, the Plumbers session would
> > be better because it can likely gather all interested parties.
> 
> Keep in mind fwctl is already at the end of a long journey of
> conference discussions and talks spanning 3 years back now. It now
> represents the generalized consensus between multiple driver
> maintainers for at least one side of the debate.
> 
> There was also a fwctl presentation at netdev conf a few weeks ago.
> 
> In as far as the cross-subsystem NAK, I don't expect more discussion
> to result in any change to people's opinions. RDMA side will continue
> to want access to the shared device FW, and netdev side will continue
> to want to deny access to the shared device FW.

As I mentioned before, this is what I hoped to mediate. The on-list
discussion has seem to hit a deficit of trust roadblock, not a deficit
of technical merit.

All I can say is the discussion is worth a try. With respect to a
precedent for a stalemate moving forward, I point to the MGLRU example.
That proposal had all of the technical merit on the list, but was not
making any clear progress to being merged. It was interesting to watch
that all thaw in real time at LSF/MM (2022) where in person
collaboration yielded strategy concessions, and mutual understanding
that email was never going to produce.

Powered by blists - more mailing lists

Powered by Openwall GNU/*/Linux Powered by OpenVZ