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

[dungeon]

He, he, reject all DRM merge Linus, maybe they will learned it

[pal666]

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.

outside of your alternative reality he already said that he will accept dc if asked. because dc has high quality and was build tested

[MaxToTheMax]

If Linus Torvalds was serious about lowering programming errors and improving code correctness he would have had been writing code in an improved version of the C language that can catch more bugs and can better enforce code correctness.

Oh no, it's a staticdumentalist post.

[swoorup]

Oh no, it's a staticdumentalist post.

Is that even a word?

[MaxToTheMax]

Is that even a word?

It is now.

[humbug]

Spare a thought for the devs. It sucks to be publicly insulted and (effectively) have your competence questioned. Linus could have rejected it without screaming.

anyway I am impatiently waiting for a kernel which uses AMDGPU DRM for my r9 290. Until then the only way to test vulkan is using amdgpu pro driver, which I don't mind but distro support is very limited and doesn't work on newish kernels.

[jaxxed]

Spare a thought for the devs. It sucks to be publicly insulted and (effectively) have your competence questioned. Linus could have rejected it without screaming.

The aggression has always been distasteful, but that is a moot point. This approach to the kernel merge process is longstanding, and it has a purpose: to break down developer ego, and create early enough apprehension that developers will really consider code quality when developing their products early. I

It filters out a lot of effort from review that would never survive the process. Some of that effort would be valuable in the kernel, but much of it is not good enough to make it, and often driven without enough purpose to create long-standing maintainable effort. If you or your organization are not willing to stand the trial of fire, then do you have enough drive to support and maintain your code, or is it now the responsibility of everybody else?

The trick is to force yourself to not take it personally.

(note: I am not involved with the kernel at all, so it is easy for me to say that)

I think I'm also going to require the DRM pull requests to be split
up, because as it is now, I'm in the situation that I have to accept
all or nothing. Which is not good, when the "all" stuff is of this
dubious quality.

This splitting up might make sense if David is on board. The size of the DRM pushes must be massive these days. Just looking at the size of DC alone, I can't imagine having to review the whole thing. If David is willing to manage DRM as separate merge requests then a lot of this could be easier navigated.

[bridgman]

anyway I am impatiently waiting for a kernel which uses AMDGPU DRM for my r9 290. Until then the only way to test vulkan is using amdgpu pro driver, which I don't mind but distro support is very limited and doesn't work on newish kernels.

What specifically are you waiting for ? Is there some bug preventing you from using the amdgpu kernel driver today via the config options, or are you just waiting for amdgpu to become the upstream default ?

In case it helps there are some distros which are enabling amdgpu by default for CIK already.

[L_A_G]

Linus is known to hold senior maintainers to a very high standard which includes making them personally responsible for any and all serious errors regardless of the seniority of the person who made that error. He even goes as far as to consider maintainers more responsible for serious errors than the person who actually made the error when they're made by junior developers. The basic gist of the way in which he maintains the Linux kernel is that it's a chain of trust where he trusts the people beneath him to catch all the serious mistakes so he doesn't have to waste potentially hours of work going trough un-doing code merges after one of these merges contains a fault nobody down the ladder caught before he did. When he does these rants it's usually because a maintainer committed code that is in such a bad state it won't even compile, proving that the maintainer who committed it didn't even test it and thus didn't do their job.

Many people are obviously going to see Linus as the villain here, but I'm going to say that there's some bigger issues at play than a couple of angry emails with a bit of swearing in them. Airlie is a grown man and can definitely take being chewed out for his mistakes once in a while. What set Linus off this time was David Airlie committing code that wasn't just badly written, it was in such a bad state it wouldn't even compile and to make matters worse the code in question had only been committed by the developer who wrote it the day before Airlie pushed it to the Linux kernel. Neither Airlie nor anyone underneath him seems to have even tried to compile the code, meaning that there may be some serious problems in the way DRM code is maintained that absolutely need to rectified. The talk about not doing any DRM commits this kernel cycle and demanding DRM updates to be in linux-next before they're pushed into the kernel proper is obviously meant to be shield the kernel proper from mistakes like this.

For Airlie's sake I hope this was a mistake and not standard procedure as you'd expect there to be at least some testing and review of all code destined for the Linux kernel before it reaches Linus. It's also rather ironic for Airlie to rant about the quality of DAL/DC code when he himself pushed code as bad as this to Linus without as much as testing it.

[notanoob]

Spare a thought for the devs. It sucks to be publicly insulted and (effectively) have your competence questioned. Linus could have rejected it without screaming.

Personally I would rather be corrected rather than continue in error. Sure he could have handled it better but these are supposed to be professonals from red hat. I would have had a odd reaction myself if a doctor recomended I eat crap as a cure for a disease. Casual semi-noob glance at the linux kernel device tree. Excuse my noobness from not doing a mathmatical proof on the execution of this code :P.

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/drivers/gpu/drm/tinydrm/core/tinydrm-core.c

 struct drm_gem_object * tinydrm_gem_cma_prime_import_sg_table(struct drm_device *drm, 				      struct dma_buf_attachment *attach, 				      struct sg_table *sgt) { .....

Why use pointers in a memory constrained function or object like the kernel? Next exhibit

  void tinydrm_gem_cma_free_object(struct drm_gem_object *gem_obj) { 	if (gem_obj->import_attach) { 		struct drm_gem_cma_object *cma_obj;  		cma_obj = to_drm_gem_cma_obj(gem_obj); 		dma_buf_vunmap(gem_obj->import_attach->dmabuf, cma_obj->vaddr); 		cma_obj->vaddr = NULL; 	}  	drm_gem_cma_free_object(gem_obj);

Don't get me started on the wasted memory and comments style but that's just preference depending on the compiler..... This is just a single file now try compiling this pile of fun. I haven't tried yet honestly, but apearently linus was having troubles :>. I think a better question is why red hat is employing noobs (or intentionally sabotaging kernel code). Pick your poison for which is worse.