Thread (126 messages) 126 messages, 19 authors, 2024-08-16

Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

From: James Bottomley <James.Bottomley@HansenPartnership.com>
Date: 2024-07-31 12:33:39
Also in: linux-cxl, linux-rdma

On Mon, 2024-07-29 at 08:10 +0200, Greg KH wrote:
On Sun, Jul 28, 2024 at 11:49:44AM -0400, James Bottomley wrote:
quoted
On Sun, 2024-07-28 at 17:16 +0200, Greg KH wrote:
quoted
On Sun, Jul 28, 2024 at 02:18:26PM +0300, Laurent Pinchart wrote:
quoted
Hi Dan,

On Fri, Jul 26, 2024 at 05:16:08PM -0700, Dan Williams wrote:
quoted
Laurent Pinchart wrote:
quoted
I know this is a topic proposed for the maintainers summit,
but given the number of people who seem to have an opinion
and be interested in dicussing it, would a session at LPC
be a better candidate ? I don't expect the maintainer
summit to invite all relevant experts from all subsystems,
that would likely overflow the room.

The downside of an LPC session is that it could easily turn
into a heated stage fight, and there are probably also
quite a few arguments that can't really be made in the open
:-S
A separate LPC session for a subsystem or set of subsystems
to explore local passthrough policy makes sense, but that is
not the primary motivation for also requesting a Maintainer
Summit topic slot. The primary motivation is discussing the
provenance and navigation of cross-subsystem NAKs especially
in an environment where the lines between net, mem, and
storage are increasingly blurry at the device level.
Would there be enough space at the maintainers' summit for all
the relevant people to join the discussion ?
Who exactly would you consider the "relevant people" here?  It's
been a wide-ranging conversation/thread :)
This is a bit of a trick question, since there seem to be three
separate but intertwined things here

   1. What to do about cross subsystem NAKs (as in how far does one
      subsystem have the ability to NAK something another does
because
      they fear it will impact them ... passthrough being only one
      example).
   2. Industry education to help manufacturers making bad decisions
      about openness and APIs make better ones that actually
benefit
      their business in the long run.
   3. Standards for open drivers (i.e. is passthrough always evil).

1. is definitely Maintainer Summit material.
And to ask again, who do you should participate in this?
Well it's a generic process issue, so the usual suspects at the
Maintainer Summit will do, the question being how do we resolve
disagreements between subsystems that think code in one impacts
another. The answer could be what we already have: resolve it on a case
by case basis, in which case see below, but it would be interesting to
see if something better can come out.  If nothing does then no harm
done and if something comes out no-one likes then the Maintainers won't
follow it anyway.

For the specific issue of discussing fwctl, the Plumbers session would
be better because it can likely gather all interested parties.
quoted
2. was something the LF used to help us with but seems to have
foundered of late (I think on the general assumption that CNCF gets
it right, so we can stop pushing)
Based on the number of meetings and trips I keep having with
different companies over the past years, 2. is not something that the
LF is no longer doing, as they fund me doing this all the time. 
Including visiting and educating your current employer about these
very issues recently :)
I didn't say it was something you were no longer doing, I said it was
something the LF is no longer helping us do.  You doing this is great,
but you're just one person.  To scale this we need go to resources for
helping the person dealing with it on the mailing list get up the
management chain when these problems arise.  Plus probably a list of
go-to resources who're used to explaining the business end of open
source to corporate executives, just in case the person dealing with
the patches doesn't have the time or doesn't want to.

Regards,

James
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help