[PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI.
Daniel Vetter
daniel at ffwll.ch
Wed Apr 24 19:36:36 UTC 2019
On Wed, Apr 24, 2019 at 11:56:17AM -0700, Eric Anholt wrote:
> The point of this review process is that userspace using the new uAPI
> can actually live with the uAPI being provided, and it's hard to know
> that without having actually looked into a kernel patch yourself.
>
> Signed-off-by: Eric Anholt <eric at anholt.net>
> Suggested-by: Daniel Vetter <daniel.vetter at ffwll.ch>
> ---
> Documentation/gpu/drm-uapi.rst | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/Documentation/gpu/drm-uapi.rst b/Documentation/gpu/drm-uapi.rst
> index 8e5545dfbf82..298424b98d99 100644
> --- a/Documentation/gpu/drm-uapi.rst
> +++ b/Documentation/gpu/drm-uapi.rst
> @@ -85,7 +85,9 @@ leads to a few additional requirements:
> - The userspace side must be fully reviewed and tested to the standards of that
> userspace project. For e.g. mesa this means piglit testcases and review on the
> mailing list. This is again to ensure that the new interface actually gets the
> - job done.
> + job done. The userspace-side reviewer should also provide at least an
> + Acked-by on the kernel uAPI patch indicating that they've looked at how the
> + kernel side is implementing the new feature being used.
Answers a question that just recently came up on merging new kms
properties.
Reviewed-by: Daniel Vetter <daniel.vetter at ffwll.ch>
>
> - The userspace patches must be against the canonical upstream, not some vendor
> fork. This is to make sure that no one cheats on the review and testing
> --
> 2.20.1
>
--
Daniel Vetter
Software Engineer, Intel Corporation
http://blog.ffwll.ch
More information about the dri-devel
mailing list