On 8/7/24 02:06, Dan Williams wrote:
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.
Well, my experience does not _quite_ match this, but I fully support
the attempt to resolve it.
FWIW, we (ie 'me' with my SUSE distro hat on) are facing similar issues;
every now and again vendors come along asking us to take this very
important out-of-tree module to allow them to configure their device.
The SCSI stack is _littered_ with vendor-specific commands allowing them
to reprogram their devices (had a fun experiment once reflashing a
megaraid HBA to suddenly show up as mpt2sas ... try to code that in
command effects ...)
So yes, I'd be in favour having an interface for this kind of stuff.
Less sure if there is a generic interface to be found; what we should
try to avoid is having an too generic one (aka: send command with this
payload, get this result, and heaven knows what it did to the device).
That would surely be useful, but security and operational aspects of
that are a nightmare.
I'd be happy to participate on the discussion at LPC if and when it happens.
Cheers,
Hannes
--
Dr. Hannes Reinecke Kernel Storage Architect
hare@xxxxxxxx +49 911 74053 688
SUSE Software Solutions GmbH, Frankenstr. 146, 90461 Nürnberg
HRB 36809 (AG Nürnberg), GF: I. Totev, A. McDonald, W. Knoblich
