What I don't get is how one kernel maintainer can make such a massive decision that affects all of Linux. That's some near-totalitarian level of power.
After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.
AMD is perfectly within their rights and abilities to ship an out-of-tree driver. As I understand it, DKMS exists to make that use case easier for end users. The popular consumer-facing distros would probably make it easy as dirt to install too.
The difference between that and upstreaming into the kernel is primarily shifting some of the the maintenance burden onto the kernel developers. That comes with the condition of adding stakeholders to the driver design, not just using them as a code dumping ground.
Linus delegates authority to people he trusts. And in this case, Dave is likely representing well what Linus would do.
> near-totalitarian level of power.
I don't think you meant to use that word. Linus and the kernel contributors together own the copyrights on the kernel. It's not totalitarian for them to dictate its future. It's their creative work. It's downright egalitarian that they let you use the kernel however you like, provided that you give the source in turn to whoever you hand it to.
I suppose the intended notion, would be given the number of Linux distributions and use cases out there, the number of companies involved, the number of products built on top of the Linux kernel... it's amazing that one guy with little financial interest in the results or effects can make that call for everyone.
I'm not sure if that's a good thing or a bad thing, to be honest, it's just... particularly interesting about the way Linux works.
It's amazing that one guy with little financial interest in the results or effects can make that call for everyone.
Impartial expert judges are usually considered a good thing. Note that Dave Airlie is not acting on a whim here; the Linux development community has discussed HALs for probably 20 years and has come to the conclusion that they are a net negative. For better or worse, the Linux development process does not care about democracy or market share or vendor relations. It's a somewhat unusual way to build software, but the result pretty much speaks for itself.
That's not true, really. Many vendors keep their own in-house patches to the mainline tree, that never make it upstream for various reasons(See Android's kernel for instance). There is nothing stopping a vendor or anyone else, from publishing their own linux tree that is a fork of mainline with this AMD patch applied. Linus maintains the 'mainline' tree, just because of the history and because most kernel hackers believe in their ability to run with it, but if Linus and friends ever did something horrid, there is nothing to stop some other group of people from forking and everyone moving to said new fork. That's part of the whole point of the GPLv2 and other OSS licenses.
Not really severely. It has a few questionable tweaks here and there.
The questionable part is CPU companies not pushing for upstream integration, so you get e.g. Qualcomm Linux. In fact, the process is not pushing, it is pulling. (some people have started working on it, still long way off)
It can be done, as shown by efforts by TI, ARM and many more...
Hell, even Rockchip, Allwinner and Sony can do it, Qualcomm, Mediatek, Google and Samsung are just not doing it because they are able to skate by without doing it.
The funny part is on Windows Phone, Microsoft learned from the kernel development process and made Samsung, LG, HTC, et all upstream their drivers, whereas Google in the same position with the same vendors has not done this and thus Sony is the only OEM pushing drivers upstream.
Upstream Allwinner support is a community effort, and it takes so long to convince the kernel developers to merge code that parts are generally years obsolete by the time they're fully supported. I think the upstream support may almost be at the point that C.H.I.P could use it - but they're using a single-core SoC from early 2012. I've seen patches for basic functionality like clock controllers (without which nothing works) get stuck in endless mailing list arguments about the most elegant approach, contradictory requirements from different maintainers, all sorts. It's not working.
The kernels used by actual Allwinner-based Android devices have almost nothing in common with the upstream support. They use a completely different mechanism for describing the hardware configuration, a completely different set of drivers, and are based on a kernel that predates upstream support.
True, but what has been accomplished with the Linux Sunxi community is a shortening of that loop to bring up new boards with modern kernels, the Pine A64 for example took only a year to gain support[1], and that was around the time they actually started shipping in quantity. Additionally, many of the ethernet drivers, HDMI PHY drivers, Cedrus (provides H.264 & H.265 decoding @ 10bit) are reusable on new chips like the H5[2].
I would not expect much from Allwinner directly, but at this point there is a sizable ecosystem and mainline support for most of their chips, which can't be said for most other ARM vendors. Another aspect of this is Allwinner sells most of their chips thru multiple business units, with the silicon being exactly the same, just what is silkscreened on the top of the package being different[3].
The A64 was one of the chips whose clock controller support got stuck in mailing list hell for over a year. Currently that's planned for 4.10, basic stuff like Ethernet, USB and SD card support is still pending though: http://linux-sunxi.org/Linux_mainlining_effort I imagine they must be using a ton of patches on top of mainline to make that work.
If it was a big secret that this was how Linux worked and it took the companies by surprise, I could see how this could be a bad thing, but it never has been: Linus has always been very upfront that he is Benevolent Dictator for Life and always has the last word. Don't get onboard if you don't like that system.
Then all the Linux fans that complained to AMD that they don't deliver open source drivers should from now on better shitstorm the kernel maintainers, since AMD delivered.
AMD didn't deliver a Linux driver. They delivered a Windows driver plus a bunch of glue code that nobody really wants. In the best of all possible worlds, somebody would dissect the Windows driver for instruction and write a proper Linux driver and nobody would try to run the Windows driver as-is.
This wasn't an open source driver, this was a hardware abstraction layer that they wanted in the kernel so their Windows driver could be distributed under a proprietary license and used without a kernel recompile.
A year ago AMD said they would just use what is currently in the kernel with a few minor modifications to get their driver working in userspace, apparently they did not follow through on that though
That's how the kernel development works. As far as I can tell, if you get maintainer status from Linus you can do as you please for the understanding is that you're acting as he would.
> Given the choice between maintaining Linus' trust that I won't merge 100,000 lines of abstracted HAL code and merging 100,000 lines of abstracted HAL code I'll give you one guess where my loyalties lie.
He is acting in a way he thinks would keep Linus' trust. Also, usually the maintainers have far superior technical knowledge of their areas to Linus. I mean, Linus is just one guy and each maintainer have their own specialty.
The Good King is how Linux has come to run the world's servers. I am perfectly fine missing out on some incidental functionality here or there in order to keep this power structure which had protected the Linux kernel thus far. It seems to work extremely well.
I'd prefer to see NVidia style drivers, personally. I don't give a rat's beans if optimized video card, nic, etc drivers are open.
I just want a system that will work properly without them. Not 60FPS on Ultra settings in <game> work, I mean boot and function as a normal user's desktop.
Yeah, I don't care about nvidia drivers, either. AMD doesn't need this in the kernel anymore than nvidia does (and they don't). Kernel modules work just fine for drivers. I don't want some convoluted shit crammed into mainline because <company> chooses to ignore feedback about their code. I am perfectly fine with this one guy shooting down AMD's pretentious attitude here. If it weren't for those kernel devs, good luck getting a Linux system to "boot and function as a normal user's desktop" because of all the crap that would be in there. Like systemd, just piles of crap in a confused, kitchen-sink orgy.
I have come to fear that we will eventually need GPU drivers in the kernel directly, thanks to more and more of the graphics code out there assuming DRM/DRI etc.
After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.