Every release, there's refactoring and improvements of the kernel subsystems. They don't offer stable APIs (by design) for drivers - you need to keep it up to date.

If you want to see this for real, try getting a "code thrown over the wall once" type embedded device kernel tree, figure out the kernel version it shipped on (likely ancient), and try to apply the latest patch level for that release to it. Then resolve the inevitable issues even just applying a few minor bug fixes.

Now if you to to update to the next major kernel version, you'll start to find functions your driver tried to call aren't there, or have new function definitions. You need to dig through the code to see what's changed. Over a few major versions, you'll eventually realise this is a whole lot of bother. If you just mainline your driver, you'll no longer need to worry about this costly maintenance burden - it might well be a few engineers spending most of their time on it. That quickly adds up, and suddenly mainlining starts to make sense.

Nvidia has to keep updating their proprietary driver every release, and presumably has a few developers doing this. I can't speak for how well it works, as I always go for AMD, but other comments here seem to confirm distributions will happily break Nvidia drivers because they aren't mainline and therefore aren't tested.

The real problem lies in this practice. Which other popular system uses this approach? Windows, macOS but also open source alternative like FreeBSD all have well-defined kernel API and drivers SDK. So, not providing a standard interface but then crying for the lack of third party drivers is hypocritical: the problem is self-inflicted.

No other popular system follows the same development cycle as the Linux kernel.

There's clearly a non-zero (and indeed non-trivial) cost to providing a stable kernel driver API, and the kernel devs don't want to bear that cost, as they feel it would hold back the kernel from evolving, improving on APIs, and fixing security issues or other implementation bugs.

The other side of the coin is that closed driver developers want this stable API to reduce their own development costs, but they will not follow the "intended" workflow that reduces the ongoing maintenance cost to effectively zero.

"Pro" move is to just skip the costly maintenance and keep the kernel same, for old times sake.

Joking aside, I think a lot of this comes down to the incentives (or lack thereof) in the ecosystem - there is no real penalty for releasing an insecure product, or one that can't be kept up to date. Thus inventivising shipping on an outdated kernel you can't maintain, and never patching it.

If those shipping products had to factor in the externalities of this decision, they would rapidly be mainlining everything to reduce the costs of this. The cost of "mainlining" their code will be trivial compared to the (unmeasured) cost of the disposal of the equipment during a reasonable lifespan due to lacking updates, and the replacement of the equipment.

This is one reason why so many mobile devices run ancient kernels which can't be updated. They stopped maintaining the out-of-tree drivers so people remain permanently stuck on the latest version that still works.

Note that most of the GPU driver problems are on phones and neither RHEL nor Ubuntu officially support phones at all. And there are also many PC components that RHEL/Ubuntu don't support either, although usually that's just because the hardware is too new.

So yes.

Disclaimer, I work for Red Hat.

In the specific, I think the relevant part is whether the kernel component and the userspace component are an Aggregate or not for the purposes of GPL virality. From the gnu.org GPL FAQ:

> Where's the line between two separate programs, and one program with two parts? This is a legal question, which ultimately judges will decide. We believe that a proper criterion depends both on the mechanism of communication (exec, pipes, rpc, function calls within a shared address space, etc.) and the semantics of the communication (what kinds of information are interchanged). If the modules are included in the same executable file, they are definitely combined in one program. If modules are designed to run linked together in a shared address space, that almost surely means combining them into one program. By contrast, pipes, sockets and command-line arguments are communication mechanisms normally used between two separate programs. So when they are used for communication, the modules normally are separate programs. But if the semantics of the communication are intimate enough, exchanging complex internal data structures, that too could be a basis to consider the two parts as combined into a larger program.

I agree we're somewhere murky within the last paragraph. The mechanism is separated well enough - the kernel driver is just IOCTLs over a pipe. The semantics are certainly carrying complex internal data structures, however, those data structures aren't part of any GPL program at all.

So perhaps it's not really anti-GPL - but it is certainly useless in a fully Free environment.

I guess I'm not sure how much earlier they can bring in the main kernel than a graphics driver that doesn't even display graphics yet. Like I've seen the amount of bikeshedding that happens when talking about hypotheticals with no code to reference.

What should they have done differently in your mind?

What they should have done is approached the community with their idea and sought input on how to design their approach. We would have discussed solutions which integrated better into the existing stack. But, then they would be robbed of the chance to do a big announcement and get ahead of the press cycle with their bad driver.

It's very clearly an RFC with an eye for "how can we better collaborate and who should we collaborate with?"

I think they need to better document and support a more opensource stack on the user side of things (maybe a vulkan or mesa targeting the WDDM ioctl interface rather than on the dx12 UAPI), but those are surmountable issues, and makes it look like the amdgpu side of the house.

WSL is definitely pulling an Embrace Extend Extinguish. I am not saying the new Microsoft is the same as Ballmer's, but still.

Linus has said that he doesn't want discussions without code for the reasons I've stated.

All the complaints I've heard about how WSL didn't do the right thing make it sound like there is no right way, despite passthrough graphics drivers for otherwise totally proprietary stacks on hypervisor stacks from companies with blatant GPL violations ending up mainlined with praise (cough VMWare). And despite the fact that the only way that's been proven to virtualize graphics cards without 2stage MMUs is to replicate the host's ioctl layer into the guest. There's a reason why Virgl isn't used by anyone serious about perf, it's the fundamentally wrong architecture.

Also, VFIO mdev can be used to virtualize graphics cards to virtual machines, both nVidia and Intel. Note this is not device assignment (that's "plain" VFIO); it's the host driver exposing a partly pass-through, partly emulated device that virtualizes the host device. mdev's design was initially a Red Hat-nVidia collaboration with input from Intel (I had a small role from the Red Hat side, mostly coming up with the name :-)) and implemented by nVidia, and is used in production with both Windows and Linux guests.

And in that case too, the ioctl layer is almost entirely maintained across the boundaries like the scheme I'm saying. You need to do that or you almost certainly get a weird impedance mismatch between guest and host that destroys perf.

And Intel needs something like this either way because their hardware arch is different, and their GPU is heavily integrated with the main IOMMU.