Re: [MAINTAINERS SUMMIT] Device Passthrough Considered Harmful?

[Leon Romanovsky <leon@kernel.org>]

On Mon, Jul 22, 2024 at 02:10:04PM +0300, Laurent Pinchart wrote:
> Hi Leon,
> 
> On Mon, Jul 22, 2024 at 01:44:07PM +0300, Leon Romanovsky wrote:
> > On Mon, Jul 22, 2024 at 11:53:17AM +0300, Laurent Pinchart wrote:
> > > On Mon, Jul 22, 2024 at 10:31:19AM +0300, Leon Romanovsky wrote:
> > > > On Sun, Jul 21, 2024 at 10:25:30PM +0300, Laurent Pinchart wrote:
> > > > > On Tue, Jul 09, 2024 at 03:15:13PM -0700, Dan Williams wrote:
> > > > > > James Bottomley wrote:
> > > > > > > > The upstream discussion has yielded the full spectrum of positions on
> > > > > > > > device specific functionality, and it is a topic that needs cross-
> > > > > > > > kernel consensus as hardware increasingly spans cross-subsystem
> > > > > > > > concerns. Please consider it for a Maintainers Summit discussion.
> > > > > > > 
> > > > > > > I'm with Greg on this ... can you point to some of the contrary
> > > > > > > positions?
> > > > > > 
> > > > > > This thread has that discussion:
> > > > > > 
> > > > > > http://lore.kernel.org/0-v1-9912f1a11620+2a-fwctl_jgg@nvidia.com
> > > > > > 
> > > > > > I do not want to speak for others on the saliency of their points, all I
> > > > > > can say is that the contrary positions have so far not moved me to drop
> > > > > > consideration of fwctl for CXL.
> > > > > > 
> > > > > > Where CXL has a Command Effects Log that is a reasonable protocol for
> > > > > > making decisions about opaque command codes, and that CXL already has a
> > > > > > few years of experience with the commands that *do* need a Linux-command
> > > > > > wrapper.
> > > > > > 
> > > > > > Some open questions from that thread are: what does it mean for the fate
> > > > > > of a proposal if one subsystem Acks the ABI and another Naks it for a
> > > > > > device that crosses subsystem functionality? Would a cynical hardware
> > > > > > response just lead to plumbing an NVME admin queue, or CXL mailbox to
> > > > > > get device-specific commands past another subsystem's objection?
> > > > > 
> > > > > My default answer would be to trust the maintainers of the relevant
> > > > > subsystems (or try to convince them when you disagree :-)).
> > > > 
> > > > You know, trust is a two-way street. If you want to trust maintainers,
> > > > they need to trust others as well. The situation where one maintainer
> > > > says "I don't trust you, so I will not allow you and other X maintainers
> > > > to do Y" is not a healthy situation.
> > > > 
> > > > > Not only should they know the technical implications best, they should also have
> > > > > a good view of the whole vertical stack, and the implications of
> > > > > pass-through for their ecosystem. 
> > > > 
> > > > It is wishful thinking. It is clearly not true for large subsystems
> > > > and/or complex devices.
> > > 
> > > Are you saying that kernel communities behind large subsystems for
> > > complex devices generally have no idea about what they're doing ? Or
> > > that in a small number of particular cases those communities are
> > > clueless ? Or does that apply to just the maintainer, not the whole
> > > subsystem core developers ? I'd like to better understand the scale of
> > > your claim here.
> > 
> > I don't know how you jumped from saying "the maintainers of the relevant
> > subsystems" to "kernel communities". I'm talking about maintainers, not
> > communities.
> 
> I wasn't too sure, so that's why I asked. I have also not been very
> precise in my previous e-mails. When I mentioned trusting maintainers, I
> meant trusting the combined knowledge of the relevant maintainer(s) and
> core developer(s) for a subsystema

Unfortunately, the reason for this topic proposed for Maintainer's summit
is that the maintainer and core developers are disagree and there is no way
to resolve it, because it is not technical difference, but a philosophical one.


> The number of people that this covers, and how they collectively reach
> agreements, very much depends on subsystems.
> 
> > There is no way to know everything about everything. In large subsystems,
> > the stack above kernel is so vast, which makes it impossible to know all
> > use cases. This is why some words (... good ... whole ...) in your sentence
> > are not accurate.
> > 
> > So the idea that one maintainer somehow equal to the whole community and
> > this person can block something for other members of the larger community
> > is overreaching.
> 
> -- 
> Regards,
> 
> Laurent Pinchart