On Wed, Jul 24, 2024 at 10:02 PM Laurent Pinchart
[off-list ref] wrote:

While "userspace drivers" often cause allergic reactions, I think I
won't cause a controversy if I say that we are all used to them in
certain areas. My heart rate will increase if someone proposes replacing
a USB webcam driver with a libusb-based solution, but I don't lose sleep
over the fact that my GPU is mostly controlled by code in Mesa.

I think the key point here is that USB webcams follow a standard, and
GPUs don't.

What I get from the discussions I've followed or partcipated in over the
years is that the main worry of free software communities is being
forced to use closed-source userspace components, whether that would be
to make the device usable at all, or to achieve decent level of
performance or full feature set. We've been through years of mostly
closed-source GPU support, of printer "windrivers", and quite a few
other horrors. The good news is that we've so far overcome lots (most)
of those challenges. Reverse engineering projects paid off, and so did
working hand-in-hand with industry actors in multiple ways (both openly
and behind the scenes). One could then legitimately ask why we're still
scared.

It would be great to define what are the free software communities
here. Distros and final users are also "free software communities" and
they do not care about niche use cases covered by proprietary
software.
They only care (and should care) about normal workflows.

I can't fully answer that question, but there are two points that I
think are relevant. Note that due to my background and experience, this
will be heavily biased towards consumer and embedded hardware, not data
centre-grade devices. Some technologies from the latter however have a
tendency to migrate to the former over time, so the distinction isn't
necessarily as relevant as one may consider.

The first point is that hardware gets more complicated over time, and in
some markets there's also an increase in the number of vendors and
devices. There's a perceived (whether true or not) danger that we won't
be able to keep up with just reverse engineering and a development model
relying on hobyists. Getting vendors involved is important if we want to
scale.

If we want vendors involved, we need to build an ecosystem where they
feel invited.

We should not take as hostages our users and impose rules on how they
should build or even sell their product.

Second, I think there's a fear of regression. For some categories of
devices, we have made slow but real progress to try and convince the
industry to be more open. This sometimes took a decade of work,
patiently building bridges and creating ecosystems brick by brick. Some
of those ecosystems are sturdy, some not so. Giving pass-through a blank
check will likely have very different effects in different areas. I
don't personally believe it will shatter everything, but I'm convinced
it carries risk in areas where cooperation with vendors is in its
infancy or is fragile for any other reason.

We control what is accepted and what is not. We just need clear rules,
to avoid regressions like:
- For areas where there is a standard (NVME, UVC,...) most of the
drivers must be in-kernel, and use generic system calls.
- For areas with no standard, custom system calls are allowed, and
some part of the driver can be in userspace.
- To land a driver, there must be a full open source stack capable of
using it for standard use cases.
- If there is an established open source stack (mesa, openVINO,
libcamera...), the open source stack must be based on it.
- Vendor passthrough mechanisms are allowed for niche use cases or
development/experimentation.

I believe those rules are already in place in some subsystems. We just
have to agree what rules should apply to all the kernel by policy.

We can agree that this kind of discussion is done better face to face.

Regards!

Finally, let's not forget that pass-through APIs are not an all or
nothing option. To cite that example only, DRM requires GPU drivers to
have an open-source userspace implementation to merge the kernel driver,
and the same subsystems strongly pushes for API standardization for
display controllers. We can set different rules for different cases.

--
Regards,

Laurent Pinchart

--
Ricardo Ribalda