1. Computers
  2. Display Drivers
  3. Graphics Cards
  4. Memory
  5. Motherboards
  6. Processors
  7. Software
  8. Storage
  9. Operating Systems


Facebook RSS Twitter Twitter Google Plus


Phoronix Test Suite

OpenBenchmarking.org

Linus: What's Wrong With The Whole DRM Crowd?

Linux Kernel

Published on 19 November 2010 03:02 PM EST
Written by Michael Larabel in Linux Kernel
30 Comments

David Airlie sent in a DRM pull request to Linus Torvalds for the Linux 2.6.37 kernel this week to fix some Intel DRM driver bugs as well as one ATI Radeon KMS fix. However, this pull request sparked another rant by Linus Torvalds about the quality of the work of the open-source Linux (DRM) graphics driver developers.

Linus is known for an occasional colorful email and in the past has had a number of issues with code in the DRM sub-system, such as calling the initial Graphics Execution Manager (GEM) push by Intel as being untested crap. It was also via Linus that Nouveau unexpectedly got merged into the mainline kernel. With this 2.6.37 DRM bug-fix pull (mailing list thread), Linus has become once again frustrated. This time it's over the DRM code being messy, useless re-basing of Git trees, large amounts of DRM code always being changed later in the release cycles, and pulling "random crap" into tree.

This new code did end up being pulled into the Linux kernel and will be found in the 2.6.37-rc3 release, but below is the unhappy email from Linus.
F*%^ me, why does drm always have to be so messy?

You guys pull each others trees, and then rebase them. Yes, git is smart enough that it will merge it all fine, but dammit, now that multi-hundred-line Radeon commit exists twice in the tree. Do this:

git show --stat 16790569eddf fba4312e223f
git show --stat 21e2eae4daae a41c73e04673

and cry.

And yeah, it's ugly. And if that patch introduces a regression (which is entirely possible, it's not like it's small and trivial and obviously correct) it will just make bisection harder, and add confusion. And it's totally pointless. It only adds pain. And it makes the history harder to read.

Why did the Intel drm tree merge a patch that had _nothing_ what-so-ever to do with Intel DRM? WHY?

And why did the drm tree rebase a tree that had obviously been public and pulled from? WHY? Why did you make it public before it was ready? And/or why was it so ugly that it needed to rebase it? Why do these things keep happening?

What's wrong with the whole drm crowd? Even if it isn't rebasing, why is drivers/gpu/drm always so very visible in the later -rc trees?

I'm asking "why", but what I really want you guys to do is to ask _yourself_ why. And ask "Why is that? What am I doing wrong that this keeps happening?"

Really. Spend some time pondering. What the hell just happened, and why did it happen, and how can you guys stop doing it?

Chris: stop pulling in random crap in your tree. Do _your_ development, in your tree. Nothing else.

And Dave, I have no idea why those two commits were rebased. They seem identical in the tree that Chris had pulled. They have the same base commit. What was the point?

Linus

About The Author
Michael Larabel is the principal author of Phoronix.com and founded the web-site in 2004 with a focus on enriching the Linux hardware experience and being the largest web-site devoted to Linux hardware reviews, particularly for products relevant to Linux gamers and enthusiasts but also commonly reviewing servers/workstations and embedded Linux devices. Michael has written more than 10,000 articles covering the state of Linux hardware support, Linux performance, graphics hardware drivers, and other topics. Michael is also the lead developer of the Phoronix Test Suite, Phoromatic, and OpenBenchmarking.org automated testing software. He can be followed via and or contacted via .
Latest Linux Hardware Reviews
  1. CompuLab Intense-PC2: An Excellent, Fanless, Mini PC Powered By Intel's i7 Haswell
  2. From The Atom 330 To Haswell ULT: Intel Linux Performance Benchmarks
  3. AMD Radeon R9 285 Tonga Performance On Linux
  4. Apotop Wi-Copy
Latest Linux Articles
  1. AMD Moves Forward With Unified Linux Driver Strategy, New Kernel Driver
  2. MSI: Update Your BIOS From The Linux Desktop
  3. NVIDIA vs. AMD 2D Linux Drivers: Catalyst Is Getting Quite Good At 2D
  4. 15-Way GPU Comparison With Mesa 10.3 + Linux 3.17
Latest Linux News
  1. EXT4 In Linux 3.18 Has Clean-ups, Bug Fixes
  2. Emacs 24.4 Has Built-In Web Browser, Improved Multi-Monitor Support
  3. NVIDIA's NVPTX Support For GCC Is Close To Being Merged
  4. KDE's KWin On Wayland Begins Using Libinput
  5. Khronos Releases OpenVX 1.0 Specification
  6. Linux Kernel Working Towards GNU11/C11 Compatibility
  7. Ubuntu 15.04 Is Codenamed After A Monkey: Vivid Vervet
  8. Following GCC, Clang Looks To Default To C11
  9. Users/Developers Threatening Fork Of Debian GNU/Linux
  10. Linux 3.18-rc1 Released One Week Early With Many Changes
Latest Forum Discussions
  1. HOPE: The Ease Of Python With The Speed Of C++
  2. Users/Developers Threatening Fork Of Debian GNU/Linux
  3. Bye bye BSD, Hello Linux: A Sys Admin's Story
  4. NVIDIA Presents Its Driver Plans To Support Mir/Wayland & KMS On Linux
  5. AMD Is Restructuring Again, Losing 7% Of Employees
  6. Open-Source AMD Fusion E-350 Support Takes A Dive
  7. Upgrade to Kaveri, very slow VDPAU performance
  8. ChromeOS Drops Support For EXT2/EXT3/EXT4 File-Systems