Re: [MAINTAINERS SUMMIT] Between a rock and a hard place, managing expectations...

[Jason Gunthorpe <jgg@nvidia.com>]

On Tue, Aug 22, 2023 at 05:29:13PM +0300, Laurent Pinchart wrote:
> On Tue, Aug 22, 2023 at 10:55:13AM +0200, Greg KH wrote:
> > On Mon, Aug 21, 2023 at 05:43:21PM -0700, Dan Williams wrote:
> > > - When do vendors need to share a common ABI?
> > 
> > When they do the "same type of thing" :)
> > 
> > > - How well is our "community consensus" protocol working to give
> > >   contributors actionable feedback?
> > > - Is there more we can do to enable contributors to steer the right path
> > >   out of the expediency vs maintainability trap?
> > > 
> > > "Confidential Computing" is an example of an area with several
> > > cross-silicon-vendor implementations that continue to add features with
> > > a steady stream of upstream design decisions that cross multiple
> > > subsystems.
> > 
> > And the normal "you all need to get together and agree on an api
> > yourself, otherwise we can't take any of this" should work here, right?
> > 
> > Well, except for the groups that snuck stuff in before we realized what
> > it really was, I guess we are stuck with them.
> > 
> > Why not have the community "fight it out" among themselves first, before
> > we have to worry about it?
> 
> In some (many ?) cases, the lowest effort path is to try and sneak it in
> without us noticing rather than "fighting it out" or "designing it out"
> among themselves. There are cases where this behaviour is even the
> consensus among vendors, as they collectively prefer keeping the design
> effort low and get drivers and whole new subsystems upstream without
> taking the community interests into account at all. 

I've begun to have the opinion that the old incentive structure in the
industry has fallen apart.

It used to be that we had Customers, OEMs, OS vendors, and Chip
builders as separate entities with a strong need to work
together. Community consensus and industry standards was a good way to
make that necessary collaboration work. You could even see a buisness
alignment that participating was good for all sides.

Now we have single entities that are OEM/(Largest) Customer/OS vendor
and sometimes even Chip designer all rolled into one opaque box. They
run, and only care about, a completely proprietary stack in userspace.

Now the business alignment is gone. Replaced by a perspective that the
utility of open source and standards is not to foster collaboration
and grow the industry but to drive down cost.

This is not just a Linux problem, I'm seeing signs of similar stresses
in the standards area as well.

As a vendor, if your biggest customers are not interested in
standards, you are not going to try to make them. As a huge customer
you don't want to make standards because that would only help your
competition. Just enough commonality to lower the cost and grind the
vendors.

So, instead of nice formal standards, we get defacto standards by who
can get stuff merged into Linux. The unfortunate truth is that in many
cases Linux is not well setup to manage the inevitable conflict that
results.

> The drivers/accel/ story is a fairly good example of the conflict
> between vendors who want to disclose as little as possible and ship
> closed-source userpace, and a community that insists on having fully
> open stacks.

We've never had a clear consensus on what userspace threshold exists
for getting something into the kernel.

In practice I think we've made it far too hard to get rid of stuff
that didn't work out for whatever reason. Once you are in, you are in
forever. That puts a lot of pressure on the maintainers to get it
right the first time, whatever "right" means. Also alot of incentive
to get "in" at any cost because once you are "in" you are golden.

For instance, I recently tried to remove some totally dead and
unusable code exposing a uAPI. It clearly was snuck in only to support
some kind of out of tree patchset and proprietary userspace. I got
pushback, and left it alone.

Or if you assert drivers/accel should not have happened, why can't we
delete that directory? Otherwise we've delivered a grandfathered and
permanent competitive advantage to one device.

It is a tough problem.

Jason