Linux Graphics Drivers Could Have User-Space API Changes More Strictly Evaluated
User-space API additions and changes (granted, no ABI breakage permitted for the mainline Linux kernel) to Linux Direct Rendering Manager (DRM) drivers is done fairly easily by their developers and possibly without enough thought. Linux DRM subsystem co-maintainer David Airlie has issued a proposal that would make user-space API alterations more strictly reviewed.
In response to both the AMD Radeon and Intel graphics drivers adding new user-space APIs for user-space code that just gets "[thrown] over the wall instead of being open source developed projects" and the increase of Android drivers introducing their own UAPI headaches, Airlie is looking at enforcing more review/oversight when DRM drivers want to make user-space API changes.
The goal ultimately is to hopefully yield more cross-driver UAPI discussions and in turn avoiding duplicated efforts, ensuring good development implementations prior to upstreaming, and better quality with more developers reviewing said changes.
To make it happen, Airlie is considering making any code commits that change the user-space API be sent in separate from other pull requests. This would shine the light on changes altering the UAPI to make review and discussion easier. Airlie is also thinking of requiring pull requests that have a UAPI change to also point to the relevant user-space "client" changes in a public open-source repository.
More information on this possible new DRM policy via dri-devel.
In response to both the AMD Radeon and Intel graphics drivers adding new user-space APIs for user-space code that just gets "[thrown] over the wall instead of being open source developed projects" and the increase of Android drivers introducing their own UAPI headaches, Airlie is looking at enforcing more review/oversight when DRM drivers want to make user-space API changes.
The goal ultimately is to hopefully yield more cross-driver UAPI discussions and in turn avoiding duplicated efforts, ensuring good development implementations prior to upstreaming, and better quality with more developers reviewing said changes.
To make it happen, Airlie is considering making any code commits that change the user-space API be sent in separate from other pull requests. This would shine the light on changes altering the UAPI to make review and discussion easier. Airlie is also thinking of requiring pull requests that have a UAPI change to also point to the relevant user-space "client" changes in a public open-source repository.
More information on this possible new DRM policy via dri-devel.
9 Comments