The Linux Kernel is one of the biggest open-source projects in the world. Because of its huge complexity, it is separated into many different subsystems, each of them containing its development community and unique workflows.
The DRM is a core Linux subsystem. Its codebase is responsible for handling graphics processing in an operating system with the Linux Kernel. Under its umbrella, there are hundreds of device drivers for different GPUs, many of them having their own community. The AMD drivers represent a big slice of DRM codebase.
In AMD open-source community, there is an urge to have an open CI pipeline, focused on applying and testing in an automated way the patches sent to the mailing lists. Because of the peculiarities of kernel development, such as the use of mailing lists instead of VCS hosts and intense influence of hardware on software performance, a new layer of complexity is set upon the DevOps role in this context. Therefore, there are two main requisites to be contemplated in the kernel CI context:
This Capstone Project aims to develop the application suggested in the first item (working on the second part is desirable and an initial base for it may be prepared while developing for the tracker software, but it won't be the focus of this project). The main objective is to implement a complete software daemon to interact with the kernel lore and retrieve recent patches. It will communicate with the Lore API, track which patches have already been fetched, and register the patches in such a way it can be easily acquired by a CI server. Finally, it should be able to retrive the response from the CI infrastructure and send the report to the mail thread from the original patch.
This project will require a good understanding of the kernel lore API, to effectively track new patches. The application must be communicating with the lore frequently to obtain the newest mails. Then, it should verify if the received mails have already been tracked, if they are valid patches. The final step of the reception stage would be to produce a patch from collected mail and make it deliverable to another process (in this case, the CI pipeline).
The other funcionality of the application would be receiving the response from the CI pipeline after testing evaluation, and sending it to the corresponding mail thread.