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