It's often not easy or even possible to simply open-source the drivers. What if there are any patents at play? How about third (fourth?) party dependencies? I'm sure the legal would take major offence with slapping GPL on the code and releasing it.

I can also imagine a company like Wacom fighting cheap Chinese copies - I can't imagine persuading the business folks to make the copycat's life way easier by open sourcing the logic.

As long as Linux says it's either mainline or the highway, well, companies will be reluctant to put in the resources I'm afraid.

Patents by definition are public information.

You may have thought about trade secrets.

Nevertheless, any trade secrets which are needed in the interface that is necessary for a device to be used by its owner, can easily be reverse engineered by someone with enough money, i.e. by all the important competitors.

So hoping that not providing documentation for the interface of your devices is a method to fight your powerful competitors is an illusion.

This method works only against your normal customers, by preventing them to find reasons to buy more of your products, for applications that you do not support, e.g. use under other operating systems.

Trade secrets are useful and they may be effectively protected when they do not concern the normal operation of a product, e.g. when they are used during the fabrication of a product.

Avoiding patent infringement claims is probably a significant motivation to stay closed source. There are just too many patents on obvious solutions any engineer would come up with.

> Patents by definition are public information.

But you don't always have the right to use them, or share them.

If company A owns a patent, and company B buys a license, company B may not have the rights to release their code to GPL and share it into mainline linux.

Hm, interesting, I hadn't thought of that. I know that Linux is fine mainlining drivers and updating them whenever the ABI changes, but what's the rationale behind not offering a stable ABI?

There's been various explanations and rationales provided over the years, but from Linus' own words in 1999 (see https://lwn.net/Articles/159313/):

Basically, I want people to know that when they use binary-only modules, it's THEIR problem. I want people to know that in their bones, and I want it shouted out from the rooftops. I want people to wake up in a cold sweat every once in a while if they use binary-only modules.

The less activist stance is simply that maintaining a stable ABI requires either accumulating lots of backwards compatibility layers over time, or to stop improving certain parts of the kernel. Neither option has won out over the current situation.

I know nothing about this topic. Is there a reasonable work around to this? To provide something stable for hardware manufacturers but allowing the current kernel practices to continue?

There is none. When linus stance is, that he wants to make it intentionally hard, for binary blobs, than this won't change.

I am all for open source drivers. But I would prefer working proprietary ones, if the alternative is buggy as hell.

I think Nvidia uses their own shim layer.

I always thought they insisted on breaking ABI specifically to incentivise open-sourcing and mainlining drivers. If given a stable ABI, manufacturers have shown (as seen on Windows) that they will just release a binary driver once and never touch it again. This is a big reason why old hardware support is so much better on Linux...for the hardware that was supported in the first place of course.

Well, my old laptop (HP nc8430 from 2006) graphic card worked perfectly up to some 3.x kernel, then it lost all sync with 3.y kernels (y > x). It was an ATI X1600. There were no more recent drivers so my take is that the kernel broke it and ATI didn't spend money to make their driver compatible with newer kernels. Actually AMD because they bought ATI in 2006. I downgraded the kernel and kept using the laptop for a while. BTW, the open source driver didn't work well.

Than I had to buy a new one in 2014. I told myself, no more ATI/AMD, let's buy one with an NVIDIA card. That card is a Quadro K1100M in a HP ZBook 15. The latest binary driver supporting that card is version 418. The newest driver is 510. Apparently the next Ubuntu 22.04 is shipping with kernel 5.15 and there is a 418 package for that kernel. I wonder what the latest compatible kernel will be. Is my laptop going to die of old age before I have to replace it because I won't be able to use its graphic card anymore? BTW, the open source driver doesn't work well. I don't check it again every year. All I remember is that I couldn't work with that the last time I tried.

On the other side, my USB scanner from the 90s still works perfectly well. Same for my mouse (I don't plugin it in every year) and any disk / pendrive I care to use.

I have a ThinkPad with a Quadro 1000M from 2011. The last Nvidia driver is 390. It still works on Arch with latest kernel somehow. I doubt it has much support left as pre-2010 GPUs have been abandoned. So I wouldn't be surprised if you have a few years left + time spent on an LTS with older kernel. I recently switched to Guix and have been using Nouveau there and it's fine but I also don't need my laptop to do much beyond display windows and play the occasional video.

Nowadays and into the future, your best bet will be AMD, since their AMDGPU driver is open source, and will therefore be kept up to date without any reliance on the company.

I have maintained for some time a Linux device driver a couple of years ago.

It was not official maintenance, it was just an unmaintained open-source device driver found somewhere, which was needed for my hardware. I had to update it after every Linux kernel release in order to be able to continue to use it.

What was annoying was not the fact that almost every kernel release required modifications in the device driver, but the lack of a documentation about the kernel changes that is usable by someone who does not follow every day the kernel mailing lists.

The 3 main reasons which broke the device driver after each new kernel release were:

1. Some reorganization of the kernel header files, which moved some definitions to other header files, which were not included in the previous driver code.

2. Some structures had members added or deleted

3. Some functions had parameters added or deleted

Point 1 was easily solved by a search through the entire Linux source tree.

When structure members or function parameters were deleted, it could be hoped that it is enough to also delete them in the device driver, even if in some cases some earlier-executed initialization code had to be modified to make everything work like before.

The worst was when there were new structure members or function parameters, as there was no way to guess which values should be put in them.

Because, at least then, but I suppose that nothing has changed, there was no centralized document with the changes that need to be applied to drivers, the only way was to search the kernel mailing lists, to discover where was the patch that changed that structure or function.

That search was not too difficult, but I have never seen a message with the changes that will also explain what values must be put in the new members/parameters.

So after finding who did the changes, the mailing lists had to be searched for messages with the same authors or similar subjects to find any relevant information.

In many cases the search was too long, so it could be simpler to pass to the final solution of anything, i.e. to reading the source code of various kernel subsystems or of other device drivers, where the offending structures or functions were also used, to discover what values might be expected.

None of these activities was too difficult, but they were quite time-consuming.

What I would have expected is that anyone who makes a kernel change like that, would also write a short migration guide, saying e.g. that whoever used the previous function with 5 parameters now has to put the X value in the 6th parameter to obtain the previous behavior.

With the right documentation of the kernel changes, I could have updated the device driver in a couple of minutes every time, but, unfortunately, I have never seen such documentation.

(The "ChangeLog" of the kernel is usually completely irrelevant for device driver maintenance, because it does not list the symbols affected by changes, so when your device driver compilation stops on function or structure XYZ, you cannot search it in the ChangeLog to discover which is the change that affected it.)

agreed with your points... as a user of the current ath9k wireless problems, code changes to address security issues completely broke the wireless - for over two kernel releases until people alarmingly realized that noone was coming to help, code changers not even aware it was broken nor checked; that the interfaces were abstract, misunderstood, that even Linus broke in and said that such breakage, regression violated the system, and decided the patches be reverted. Point is, little to no documentation, and in my opinion too much fiat, with shallow testing and confirmation, and only when people howled was noticed. And this is the second time for me where I once spent days bisecting the kernel* over a year or two of changes, finally getting the chip manufacturers involved - ooops, sorry, was the response. *I realize that is my cost as a free OS user, but still, I'm not a developer and they shouldn't be pulling the rug out under us.

Imagine if you could resolve such conflicts in a few minutes. The code editor should also be a collaboration tool.

Using an online editor, Mark a struct for changes…call a merge meeting with all affected module owners and everyone changes their code right there and then.

Even using email to talk about code is stupid and an unnecessary hurdle.

The two are related. Offering a stable ABI would discourage hardware manufacturers from mainlining drivers.