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

[Linus Walleij <linus.walleij@linaro.org>]

On Thu, Aug 24, 2023 at 2:47 AM Jason Gunthorpe <jgg@nvidia.com> wrote:
> On Tue, Aug 22, 2023 at 05:29:13PM +0300, Laurent Pinchart wrote:

> > 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.
(...)
> 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.

I have a more optimistic view.

Maybe it depends where you look.

When Android appeared in 2007 and especially after Nexus One in 2010
the Linux handset industry was running to catch up with Apple iPhone,
and they didn't focus much about working upstream, at times implying
the Linux kernel was even interchangeable to them.

Since then they come a long way, after a few generations of lost
hardware that the kernel never supported properly, Android is
pushing the Generic Kernel Image and being more restrictive about
proprietary extensions every day. It's going the right way.
Todd Kjos at Google and Greg Kroah-Hartman from the community
have been instrumental here.

For deeply embedded silicon even in datacenters, companies like
Red Hat have pushed the vendors to work upstream because they
don't want to carry any custom patches. Jon Masters has been
instrumental here, requiring upstream drivers and ACPI support for
server silicon.

Qualcomm is working with a strong upstream focus. I think this is driven
by both handset Android and laptop ChromeOS work. They do a great
job minimizing their upstream gap.

There are problematic areas, I would point to any firmware that talks
directly to userspace such as sensor hubs (Android still isn't using the
IIO subsystem...)

> 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.

But Google and Red Hat acted as responsible "big customers" in a
sense, those put requirements on hardware vendors wanting to run
their userspace with full support from the vendor.

> > 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.

If you want to push it, Alyssa showed only two days ago what *can* be
done: fully conformant OpenGL ES 3.1 with open drivers is *possible*
to do using just open tools. If Alyssa can do it for her driver, why can't
nVidia, Intel, AMD...
https://rosenzweig.io/blog/first-conformant-m1-gpu-driver.html

For drivers/accel I was under the impression that since LF is backing
PyTorch that would be the default userspace, but I don't know how they
stand with that as it seems CUDA-centric for accelerators, and
admittedly I don't know what conformance would mean in that case.
What is even the backend API for an accelerator userspace?
CUDA and OpenCL?
Or something new I haven't even heard of yet?

> 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.

I guess you are referring to the uAPI and userspace exercise tools.

For GPIO (admittedly a smaller problem than GPU) we simply made
a new uAPI to supercede the old one when it didn't work out.
It's the usual: always plan to throw the first version away.
The first one wasn't useless, it was useful to see what was needed
for the second version. We will get rid of the first version eventually,
just like Video4Linux is now replaced with V4L2. Maybe it is a bit
un-elegant to carry two uAPIs for a time, but I think it is simply
normal for our business to end up with that.

For in-kernel APIs we are doing this so often it isn't even funny,
such as network devices "napi" (new API), or the block layer mq
(multiqueue) that gradually but eventually completely replace the
old APIs.

> 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.

That's depressing. I recently ran into that as well, but it didn't seem
impossible, instead I was asked to begin with marking it broken:
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=8f0adae1cb1a3cf83e38dd435831baa38dd84b4c

Can you try that approach? When it's been broken for a while and
nobody cared to fix it, certainly it can be deleted.

Yours,
Linus Walleij