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 reconsideration of the "debug-build only" policy for CXL device-specific commands was influenced by a conversation with a distro developer where they asserted, paraphrasing: "at what point is a device vendor incentivized to ship an out-of-tree module just to restore their passthrough functionality?. At that point upstream has lost out on collaboration and distro kernel ABI has gained another out-of-tree consumer." So the tension is healthy, but it has diminishing returns past a certain point.
