Hacker News Reader

Comment by zznneezznnee | Hacker News Reader

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.

View on HN

Then 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!).

AMD 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.

My 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-Februa...

> 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.

> 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.

Define "good" and "software."

This 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.

Developers 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.

This is why—effectively—use and application of Linux is limited to developers.

> 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.

Without any conflict, uh?

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.

> 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.

Out 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.

Sarah Sharp worked for Intel and apparently didn't manage to contribute to the kernel in a way that would make communication with Torvalds particularly pleasant.

I extend my sympathy to anyone paid to contribute code to Linux.

She never had any unpleasant communication herself, for what it's worth.

Most people who are paid to contribute to Linux, including myself, are very happy to do so, and no, it's not a case of Stockholm syndrome.

to me Sharp came across as trying to score social points by being a "woman in tech" rather than being honesty interested in tech. Something i fear is going on a whole lot in recent years in the FOSS world.

I keep seeing already cash strapped projects go off the rails because someone decides that they need a gender oriented outreach program, complete with elaborate gatherings and whatsnot.

And when that crash and burns, their excuse for the cash bonfire is that the FOSS world is misogynistic...

> Maybe the 2 should ask Intel for some pointers on how to contribute to the kernel the right way.

Intel is not waiting for them to ask:

https://lists.freedesktop.org/archives/dri-devel/2016-Decemb...

> This is something you need to fix, or it'll stay completely painful forever. It's hard work and takes years, but here at Intel we pulled it off. We can upstream everything from a _very_ early stage (can't tell you how early). And we have full marketing approval for that. If you watch the i915 commit stream you can see how our code is chasing updates from the hw engineers debugging things.

(More specific advice follows.)

Reply on news.ycombinator.com