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: > > On Sun, 2024-07-28 at 17:16 +0200, Greg KH wrote: > > > On Sun, Jul 28, 2024 at 02:18:26PM +0300, Laurent Pinchart wrote: > > > > Hi Dan, > > > > > > > > On Fri, Jul 26, 2024 at 05:16:08PM -0700, Dan Williams wrote: > > > > > Laurent Pinchart wrote: > > > > > > 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. > > 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
