After reading the arguments, I'm kind of on AMD's side. I get what Dave wants, but it seems extremely idealistic.
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.
"Totalitarian" seems a bit over the top.
> 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'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.
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.
They want it in kernel, however, and that means they have to play by the in kernel rules.
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
Which are running a severely modified kernel because the process of going through mainline to get it mobile ready would be far too painful.
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...
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.
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.
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].
1 - http://www.cnx-software.com/2015/11/10/allwinner-a64-datashe... and https://forum.armbian.com/index.php/topic/1917-armbian-runni... 2 - http://www.cnx-software.com/2016/08/17/allwinner-h5-is-a-qua...
3 - https://forum.armbian.com/index.php/topic/2099-crypto-engine...
> 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.
> After reading the arguments, I'm kind of on AMD's side.
And that's why stuff like this doesn't get put to a vote.
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.
Of course companies had an agenda to improve it to the point they wouldn't need to keep paying Sun, SGI, HP, IBM, Compaq, Unisys,...