DRM CI Merged Into Linux 6.6 – Linus Torvalds: “Let’s See Where It Goes”


In addition to all the open-source kernel graphics/display driver updates for Linux 6.6, merged this afternoon ahead of the Linux 6.6-rc1 tagging is merging of the DRM continuous integration (CI) code to hopefully lead to better testing of DRM subsystem/driver changes.

Now upstreamed into the mainline Linux kernel is the DRM CI integration that is used by the FreeDesktop.org GitLab to facilitate user-space testing across various GPUs of DRM changes pending for the kernel.

David Airlie commented in the DRM CI pull request:

“From my perspective I think it’s an experiment worth going with and seeing how the benefits/noise playout keeping these files useful.

Ideally I’d like to get this so we can do pre-merge testing on PRs eventually.

Below is some info from danvet on why we’ve ended up making the decision and how we can roll it back if we decide it was a bad plan.

Why in upstream?

– like documentation, testcases, tools CI integration is one of these things where you can waste endless amounts of time if you accidentally have a version that doesn’t match your source code

– but also like the above, there’s a balance, this is the initial cut of what we think makes sense to keep in sync vs out-of-tree, probably needs adjustment

– gitlab supports out-of-repo gitlab integration and that’s what’s been used for the kernel in drm, but it results in per-driver fragmentation and lots of duplicated effort. the simple act of smashing an arbitrary winner into a topic branch already started surfacing patches on dri-devel and sparking good cross driver team discussions

Why gitlab?

– it’s not any more shit than any of the other CI

– drm userspace uses it extensively for everything in userspace, we have a lot of people and experience with this, including integration of hw testing labs

– media userspace like gstreamer is also on gitlab.fd.o, and there’s discussion to extend this to the media subsystem in some fashion

Will we regret this?

– it’s all in one directory, intentionally, for easy deletion

– probably 1-2 years in upstream to see whether this is worth it or a Big Mistake. that’s roughly what it took to _really_ roll out solid CI in the bigger userspace projects we have on gitlab.fd.o like mesa3d”

Adding all of these DRM CI files to the mainline kernel adds 5.5k lines of new text files, YAML files, and other bits used by their GitLab CI infrastructure for facilitating the pre-merge testing.

Phoronix graphics card testing array

Linus Torvalds has decided to accept this DRM CI integration into the mainline kernel to see how it plays out. After deciding today to go ahead and merge the DRM CI bits, he wrote on the mailing list:

“So I finally had no other pull requests pending, and spent some time looking at this, and I see nothing offensive.

I did wonder how this then expands to having more than one subsystem using this (and mixing them possibly on the same CI system), but that’s more about my ignorance about how the gitlab CI works than anything else, so that’s certainly not a real concern.

The other side of that “I do wonder” coin is for when others want to use the same tests but using some other CI infrastructure, whether it’s some AWS or google cloud thing, or github or whatever.

Anyway, considering that both of my idle curiosity reactions were about “if this is successful”, I think me having those questions only means that I should pull this, rather than questioning the pull itself.

If it works out so well that others want to actually do this and integrate our other selftests in similar manners, I think that would be lovely.

And if – as you say – this is a failure and the whole thing gets deleted a year from now as “this didn’t go anywhere”, it doesn’t look like it should cause a ton of problems either.

Anyway, it’s in my tree now, let’s see where it goes.”

We’ll see over the next year if carrying this CI integration bits in the mainline kernel pays off and if it leads to any broader continuous integration efforts within the Linux kernel upstream community.