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@xxxxxxxxxx > > > > > > > > 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. 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. Thanks > > -- > Regards, > > Laurent Pinchart
