On Sun, Dec 18, 2016 at 3:23 AM, Daniel Campbell <z...@gentoo.org> wrote: > > Thankfully the kernel seems to have sane management; as long as Linus is > around, anyway. Just recently AMD had some of their code rejected, so > with a vigilant-enough team, you can effectively protect your project > from monied interests (be it poor code or an attempt to manipulate). Now > picture what might have happened if AMD was employing Linus or had some > other sort of contract. (For the record, I use an AMD CPU and like it; > they just happened to be the most recent corporation who's rejected code > popped on my radar. No bias intended.) >
I think this is an oversimplification of the issues involved in the AMD situation, which as with so many of these things people just jumped on picking sides. And I think what has gotten lost is an issue that actually comes up somewhat often in FOSS. Let's step back and look at the reality in the gaming on Linux domain: there are basically two GPU manufacturers in the game (AMD/NVidia), and neither one has their best GPU drivers in the mainline kernel. Both of them contribute to drivers which ARE merged into the kernel, but in both cases these lack features found in the out-of-mainline module. AMD has been attempting to merge their better driver into the mainline kernel. As far as I'm aware (I could be wrong) Nvidia hasn't really tried to do this for the most part and are content to just keep shipping a blob. AMD's reasons are certainly at least somewhat selfish, as maintaining all that code out-of-tree is expensive since linux doesn't have a stable API for drivers. Ok, AMD wants to add a more capable driver to the kernel, and obviously Linux users would prefer a more capable driver in the kernel, so what is the problem? And this is where we come to an issue that happens from time to time in FOSS: the needs of the kernel maintainers are not aligned with the needs of the AMD driver maintainers. The AMD and NVidia out-of-mainline drivers both use an abstraction layer to map the kernel APIs to an internal set of APIs used by the driver, because their drivers are multi-platform. I'm not sure exactly how their internal APIs work in both cases. They might internally target the Windows APIs, or they might even target a virtual API and use a translation layer on every platform. This allows them to use one set of code for their core logic across all platforms, at the cost of overhead on Linux (and possibly on other platforms as well). On most platforms this is no big deal because the APIs on those platforms are stable. On Linux this is not the case, and the maintainers prefer to have the freedom to modify their internal APIs and not maintain their own translation layers for backwards compatibility. IMO both sides are basically "right" in their designs, because they have different priorities. The AMD driver code isn't "poor code" - it just isn't natively written for Linux and so it has a lot of code that is theoretically unnecessary (in a world where all devices run Linux). And that is of course more code for the Linux maintainers to deal with if they accept the driver into mainline. On the other hand, writing a driver that purely targets Linux means having to change the core part of the driver anytime the Linux APIs change, which then means changing the translation layers on every OTHER platform out there, when those platforms otherwise feature stable APIs, or having a 3-layer solution (Linux to single virtual API to various stable platform APIs). Now, if the Linux maintainers wanted to have a stable API but wanted to refactor their code internally, then you could actually have a multiple-layer situation as well. You could have Linux internal APIs to Linux stable API to AMD virtual API translation going on (which I suspect is what happens on Windows). As far as I'm aware Microsoft doesn't care if vendors use translation layers, because they don't touch those modules other than testing them (which they get paid to do anyway). Both sides of this debate can legitimately cite maintainability as a reason to not give in. The Linux guys don't to have to maintain a de-facto stable API (which is what the translation layer turns into). The AMD (and NVidia) guys don't want to write a different driver on every platform. Keep in mind that besides Windows and Linux, they may have multiple test harnesses that they need to map into their drivers, and probably other OSes as well. There is also a huge benefit to having the same bug list on every platform for the most part. And Linux users benefit when the "Optimized for <AAA title here>" work done for Windows automatically hits Linux as well, which gives the publisher more incentive to spend the extra few bucks to release a Linux version of the game. So, saying that this is about moneyed interests trying to somehow corrupt the "purity" of FOSS isn't really right here. Ultimately issues like this become a bit of a tragedy for all. And mind you, I'm not trying to say that the Linux maintainers should ignore their own interests and just merge the code. If one side was right and the other was wrong it wouldn't be the problem that it is. And stuff like this is what leads to this thread. Did the Firefox maintainers HAVE to require Pulseaudio? Of course not. Are they going to be bothered to not require it for the sake of the 0.1% of Linux users who want to use a web browser but don't have Pulseaudio running? Probably not. The universe of Linux systems that are running Firefox but not Pulseaudio is fairly small at this point. >From their standpoint requiring it costs them nothing and makes their life a tiny bit easier. I'd love to live in a world where all the code that everybody wants exists for free and any subset of it is interoperable with any other subset of it. However, that just isn't going to happen because all the necessary translation layers needed to make that happen are a pain to maintain. And so in a sense the same reasons that drove the Linux maintainers to reject the AMD code are the same sorts of reasons that are going to drive the Firefox maintainers to reject any patches that let their software work without Pulseaudio, which brings us full circle... :) -- Rich
