DRM Updates Submitted For Linux 4.11, Torvalds Explodes Over Code Quality

[Sethox]

You can see those that disagree Linus spout aggression like a child are not aware of the line of work Linus is doing.

The day he gets chill and just do the work regardless of what code it is, that is the day he has given up caring about the Linus Kernel (accepting faulty code), I for one do not want that. Linus could have handled it better but those that does not UNDERSTAND why he act this way should keep in mind his importance in the industry, AKA he is an hardass for a very valid reason.

Note: Not excusing Linus for his behavior, never will. I just understand his positioning and frustration.

[carewolf]

Wow, that code must be really disastrous.

It didn't compile. It is a rather big flaw in software.

[c117152]

Being fair, graphics driver in linux been atrocious going back decades. Open or closed... Intel's Nvidia's or AMD's... Peripheral or SoC die integrated... I can't remember a single piece of hardware not tearing AND crashing and often taking the whole system with it.
Not to say it's significantly better with Windows... Just saying it's nothing new.

[L_A_G]

Being fair, graphics driver in linux been atrocious going back decades. Open or closed... Intel's Nvidia's or AMD's... Peripheral or SoC die integrated... I can't remember a single piece of hardware not tearing AND crashing and often taking the whole system with it.
Not to say it's significantly better with Windows... Just saying it's nothing new.

There's a difference between garden variety buggy code and code so buggy it won't even compile (which is what made Linus have a closer look at the code). Hence the talk about how he thought the code was so immature it hadn't even seen a compiler before his attempt to compile the code. When he probably had to spend a great deal of effort undoing code merges because of something that obviously should have been caught much further down the maintainer ladder you can understand why he's being so grumpy.

[boffo]

Good reminder to those few people think that he'll just accept the AMDGPU DC code as a placeholder to get the cards supported that he almost certainly wont. Not saying his atitude's a great thing but it's what you need to work around cause he aint mellowing out as he gets older

True story

[M@yeulC]

https://kernelnewbies.org/Linux_4.10...2c71a859dcc184

did you try that? Also, that is not the cpu scheduler's fault when i/o is concerned.


Personally i think Linus makes the right decisions, as they prevent technical debt increase in the future. Not merging some dubious code now means that next time it comes up, it will be in much better shape and less end users will complain about build issues or instability.

Wasn't it caused by hugepage defrag?

echo never > /sys/kernel/mm/transparent_hugepage/[I]defrag[/I]

seems to give quite good results for me. I wish this problem was solved in default configurations.

[chithanh]

He's generally ok with code that's ugly as long as it all works properly and is well tested. Check out the kdbus topic, for example. Linus wasn't real thrilled by that code, but ultimately it seemed like he would have merged it all if there was general agreement to have it go in. It was only all the vigorous objections that got him to finally reject it.

Actually, Linus' reservation was a combination of multiple issues. In particular, he exposed the performance argument for kdbus as mostly bogus:

I have to admit to being particularly disappointed with the performance argument for merging it. Having looked at the dbus performance, and come to the conclusion that the reason dbus performs abysmally badly is just pure shit user space code, I am not AT ALL impressed by the performance argument. We don't merge kernel code just because user space was written by a retarded monkey on crack. Kernel code has higher standards, and yes, that also means that it tends to perform better, but no, 'user space code is shit' is not a valid reason for pushing things into the kernel. So quite frankly, the "better performance" argument is bogus in my opinion. That still leaves other arguments, but it does weaken the case for kdbus quite a bit.

In the end, kdbus wasn't rejected, it was withdrawn.

[nanonyme]

It is an interesting call he makes as well with PR size. Maybe there's something fundamentally wrong with how DRM PR's are managed if Linus can't accept the good stuff and discard the bad stuff until next merge window

[robclark]

It didn't compile. It is a rather big flaw in software.

to be fair, it sounded like a kconfig issue (ie. it compiles properly if you have the right kernel config, but not otherwise.. so probably missing some "selects" in Kconfig file).. that sort of thing is rather easy to mess up, given how much build-time configurability there is in the kernel.

[W.Irrkopf]

Phoronix: DRM Updates Submitted For Linux 4.11, Torvalds Explodes Over Code Quality

David Airlie submitted the main DRM driver updates for the Linux 4.11 kernel, but Linus Torvalds isn't happy about the code quality of a new addition and is considering not accepting the DRM changes for this next kernel release...

http://www.phoronix.com/scan.php?pag...tes-Linux-4.11

I looked at the mail thread in question and it looks that what triggered the outburst was a KCONFIG issue and warnings during compilation. I also looked at the dri-devel thread which seems to indicate that the developer wrote the code for his system (well archictecture actually) and Linus tried to build it on another. So whether the actual c-code is good or bad - I can't tell, but Linus shouting was at his subsystem maintainer to not detect and fix this earlier. Well, in fact Dave saw at least some of the warnings and asked the author to fix them while still accepting the original pull request.