linux-kernel - Re: [PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Wed, 24 Apr 2019 21:36:36 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Eric Anholt <eric@...olt.net>
Cc:     dri-devel@...ts.freedesktop.org, Dave Airlie <airlied@...il.com>,
        linux-kernel@...r.kernel.org,
        Daniel Vetter <daniel.vetter@...ll.ch>
Subject: Re: [PATCH 2/2] drm/doc: Document expectation that userspace review
 looks at kernel uAPI.

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@...olt.net>
> Suggested-by: Daniel Vetter <daniel.vetter@...ll.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@...ll.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