Just curious: if someone was inclined to build a set of good (correct style, well-documented, etc) patches to support those extensions, why would the kernel refuse them?
(Put another way: I'm wondering whether you think the difficulty is technical or political.)
This is a great example of how bad many open source projects are at accepting contributions from 'non core' developers. The patch is just rejected, when it actually looks pretty valid to handle all cases of return value from a kernel interface. While it might not be a perfect solution, accepting it with suggestions for additional improvements could have led to those improvements.
As can be seen from the patchset, there's no conceivable way it could be built into the kernel without having the kernel build depend on proprietary headers, effectively disqualifying it entirely. This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel.
The kernel shipped with Ubuntu has hundreds of patches. They simply don't bother sending them upstream. Whether this is because they don't care, because they know they are poor quality and would be rejected, or because they want to "differentiate" I do not know.
As I have said already, which you seem to be ignoring:
"This all-important fact is revealed in the very last patch of a 21-patch patchset, wasting everyone's time, and a lot of it. It's either utter carelessness, stupidity, or outright malice to ask for something like this to be included into a loudly-and-clearly GPL-licensed kernel.
----
In the end, all I have to say to you is:
If I walk up to you in the street and slap you in the face, unprovoked, surely the noble thing for you to do is to politely tell me off; but I will not hold it against you if you were to lose your cool and retaliate.
Why? It's not as if CK is trying to get it into the mainline.
What does one have to do with the other? If I'm going to spend the necessary 20 minutes to compile a new kernel using CK's patch, I want some evidence that I'm going to be gaining something.
I know this isn't the opinion of many kernel developers, but I think a lot of the problems encountered are better solved by removing proprietary GNU C extensions from the kernel code. I would love to start sending patches but I expect they'd just be NACKed.
Because kernel developers can only work with what they're given. If the hardware isn't supplied by the company or some grant, or if it's IP encumbered, then you have a situation where it's unlikely to be supported natively by the kernel.
At that point, it becomes a short-term or long-term benefit assessment. Long-term, it's better to work to get it accepted upstream, but that's more work in that you have to make sure your patch is acceptable and conforms to how the kernel devs want it, and they can verify the support works, instead of just working as you've set up in-house. With the rush to market, and with the specific configuration of chips possibly not being used in the next item released, short-term patches likely look really attractive.
Nope, because Intel can just push some binary drivers out and everyone will down it with a gargle.
The kernel patches are refused because the kernel devs expect to maintain the code for as long as there are devices in active use that need it once allowed in.
Thus they demand a proper spec for the device behavior so they can test for breakages down the line. And apparently the patches are already violating AHCI behavior expected by the kernel.
Or at least that is what i got out of reading the short ML thread.
The non-litigious nature of the kernel devs seems to keep this from kicking off. It would probably end up hysterically expensive for all concerned and be a bit of a PR failure I guess.
> and the only way to avoid the associated issues is to mainline drivers, which most companies don't want to do (... don't want to invest in maintaining it etc.)
They wouldn't have to, that would be done for them, for free, if they got their code into the kernel...
> Are they independent from torvalds' kernel? I thought the kernel was patched very quickly (KPTI)?
They have to package the kernel for Ubuntu and compile it with whatever modules are standard for them. Plus perhaps applying some distro-specific patches (I don't know if Ubuntu does this), and testing.
The sad answer is that they can't be bothered to meet the quality standards expected for upstream kernel code. Easier to just throw garbage in a tarball and ship privesc vulnerabilities to millions of users.
Are you telling me that the richest and most valuable company in the world can't coordinate security patches of two of its biggest OSes that share a lot of kernel code?
reply