In addition to all open source kernel graphics/display driver updates for Linux 6.6, merged this afternoon in advance of Linux 6.6-rc1 tagging was a merge of DRM continuous integration (CI) code and DRM It is hoped that this will lead to better testing of subsystems. Driver changes.
Currently upstreamed to the mainline Linux kernel is the DRM CI integration used by FreeDesktop.org GitLab to facilitate user-space testing across various GPUs of pending DRM changes in the kernel. .
David Airy commented: DRM CI pull request:
“From my point of view, I think this is a worthwhile experiment to see how the benefits and noise playback will be while preserving the usefulness of these files.
Ideally, I would like to have this so that I can eventually run pre-merge tests in PR.
Below is information from danvet about why he ultimately made his decision and how to reverse it if you decide it was the wrong plan.
why upstream?
– Documentation, test cases, tools, etc. CI integration is one of those things where you can waste endless hours if you accidentally use a version that doesn’t match your source code
– But as above, there is a balance, and this is the first part where it seems reasonable to keep it in sync with outside the tree, and will likely require adjustment.
– gitlab supports gitlab integration outside the repository, which is used in the DRM kernel, but it introduces fragmentation and a lot of duplication of work per driver. The simple act of knocking any winner into a topic branch has already started surfacing patches in dri-devel and sparking some good cross-driver team discussion.
why gitlab?
– less shit than other CIs
– drm userspace uses this extensively for everything in userspace. We have a lot of talent and experience in this, including integrating hardware test labs.
– There is also a gstreamer-like media userspace in gitlab.fd.o, and there is discussion about extending this into a media subsystem somehow.
…
Will we regret this?– All intentionally grouped together in one directory for easy deletion.
– It will probably take a year or two upstream to determine if this is worth it or a big mistake. This is the approximate cost required to actually deploy solid CI in a larger userspace project 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 the GitLab CI infrastructure to facilitate pre-merge testing .
Linus Torvalds decided to accept this integration of DRM CI into the mainline kernel and see how it would work. Today, after deciding to merge the DRM CI bits, he wrote: mailing list:
“So I finally had no other pull requests pending, and I took the time to look into this one and didn’t find anything objectionable.
I was wondering how this would scale to multiple subsystems using this (perhaps mixed on the same CI system), but it’s more my understanding of how gitlab CI works than anything else. That’s certainly not a real concern since it’s due to ignorance.
The other side of the “wonderful” coin is when other people want to use the same tests, but use other CI infrastructures like those from AWS or Google Cloud, or github.
Anyway, given that both of my idle curiosity reactions are about “will this work or not”, those doubts are less about pulling this than having doubts about the pull itself. I think it just means that there is a need.
I think it would be great if it worked so well that other people actually want to do this and integrate other self-tests in a similar way.
And if, as you say, this was a failure and the whole thing was removed a year later as “this didn’t work”, I don’t think it would cause much of a problem.
Anyway, it’s on my tree now, so let’s see where it goes. ”
We’ll see over the next year whether bringing this CI integration bit into the mainline kernel is effective and whether it leads to broader continuous integration efforts within the Linux kernel upstream community.