5 ms·
The kernel maintainers don't necessarily want your code. Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream main
by zznneezznnee 10y ago
The kernel maintainers don't necessarily want your code.
Additional shit in mainline increases the maintenance burden. If the code isn't putting upstream maintainability above all else in its implementation, then it's generally not getting merged unless someone wasn't paying attention or some other forces compelled an exception.
Alex's first reply reads like he's willfully ignoring that aspect of the NACK. It's not a coding style issue, it's a HAL issue. Upstream isn't interested in maintaining a HAL and living with the impedance mismatch from day zero. The driver can stay out of tree. This is just about code getting into mainline.
I'm personally very happy to see the gpu subsystem maintainers paying attention and having the maturity to know a fool's errand when they see it.
- izacus 10y agoThen again, we're not talking about some wierd network card driver here. We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer. A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. While I get the reasoning for rejection, the typical OSS rejection attitude is also problematic. I kinda don't see a dialog happening here on how to resolve problems both sides have, just a repeat of posturing which has historically brought us awesome things like binary blob drivers that only work with single version of kernels (yes, I'm looking at you every ARM GPU ever!).
- x0x0 10y agoAMD was told in February that they would have to obey kernel code standards / no HAL. In late October they dropped a steaming pile of 100k lines of code with a HAL and are whining it isn't getting merged. The solution is AMD keeps code out of mainline or obeys kernel code standards.
- ChoGGi 10y agoMy favorite part is back in February they made mention of shrinking it to 1/3 of what it was (93KLOC). Now we're up to 100K+ https://lists.freedesktop.org/archives/dri-devel/2016-February/100715.html https://lists.freedesktop.org/archives/dri-devel/2016-Februa...
- wyldfire 10y ago> A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. Who's to say its replacement will be any better? If the hygiene isn't there, maybe the quality isn't either.
- snarfy 10y ago> A driver which has caused a large amount of desktop users to return to Windows due to its historical issues. Kernel developers do not care. They care about good software.
- calinet6 10y agoDefine "good" and "software."
- calinet6 10y agoThis got into negative territory, but I was being serious. Define "good." Is quality a thing just defined by code style and properness, or is it defined as fitness for a purpose, connection to human use and usefulness, usability or function, or lack of defects to the end user? Define "software." Is software just code, or does it also include the experience the code generates for the user? Is software only considered in terms of what developers of software are interested in, or does it include what users need and want? Of course Linux kernel developers are only interested in narrow definitions of those things, and that's surely part of the problem. It's good to think about what "good software" really means, in my opinion.
- snarfy 10y agoDevelopers are also users, and a part of the application they use is the source code. Having good quality source code benefits all users, not just developers. Linux is where it is today because of the quality of the code. Things like "use and usefulness, usability or function" have different meanings to a developer looking at the source code.
- calinet6 10y agoThis is why—effectively—use and application of Linux is limited to developers.
- sangnoir 10y ago> We're talking about having a constant up-to-date driver on par with Windows for a major GPU card manufacturer Nvidia manages to do this without any conflict with the kernel maintainers by simply not mainlining the code. If functionality trumps code quality, AMD can release kernel modules. Perhaps the best current solution for all parties is for AMD publish sources on github and release kernel modules while getting PRs from the community to get the code up to meet the kernel standards. When the time comes, it will be duly mainlined.
- StRoy 10y agoWithout any conflict, uh? https://www.youtube.com/watch?v=iYWzMvlj2RQ https://www.youtube.com/watch?v=iYWzMvlj2RQ > Nvidia has been the single worst company we've ever dealt with. > - Linus Kernel devs are antagonizing the only two GPU makers that matters. Besides the kernel, there has been some flame going between NVIDIA and Wayland devs too. Open source devs are immature men who do not understand the word compromise.
- sangnoir 10y ago> Without any conflict, uh? > Nvidia has been the single worst company we've ever dealt with. > - Linus This had nothing to do with the kernel and everything to do with the lack of optimus support (years later, its still shit). > Kernel devs are antagonizing the only two GPU makers that matters Maybe the 2 should ask Intel for some pointers on how to contribute to the kernel the right way. > Open source devs are immature men who do not understand the word compromise. I suspect that's part of the reason the kernel is stable, and for that I'm thankful. Not compromising on code quality is something I wish more projects would do, if they had the well-earned political/social capital the Linux kernel has.
- Freak_NL 10y agoOut of the three common GPU brands found in computers nowadays, Intel's integrated GPUs have mostly been a very pleasant experience for the end user when installing any GNU/Linux distribution. It just works without any additional work. If AMD manages to reach that level of out-of-the-box working graphics driver, that will definitely reflect positively on their brand of graphics cards, and might give them an advantage over Nvidia. I suspect that working with the kernel developers and maintainers will also be beneficial to the driver itself. It seems to me that for cooperating you gain valuable feedback on your code from people well-versed in kernel and driver code.