From: Daniel Vetter <daniel@ffwll.ch> To: Eric Anholt <eric@anholt.net> Cc: dri-devel@lists.freedesktop.org, Dave Airlie <airlied@gmail.com>, linux-kernel@vger.kernel.org, Daniel Vetter <daniel.vetter@ffwll.ch> Subject: Re: [PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI. Date: Wed, 24 Apr 2019 21:36:36 +0200 [thread overview] Message-ID: <20190424193636.GU9857@phenom.ffwll.local> (raw) In-Reply-To: <20190424185617.16865-2-eric@anholt.net> 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@anholt.net> > Suggested-by: Daniel Vetter <daniel.vetter@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@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
WARNING: multiple messages have this Message-ID (diff)
From: Daniel Vetter <daniel@ffwll.ch> To: Eric Anholt <eric@anholt.net> Cc: Daniel Vetter <daniel.vetter@ffwll.ch>, linux-kernel@vger.kernel.org, dri-devel@lists.freedesktop.org Subject: Re: [PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI. Date: Wed, 24 Apr 2019 21:36:36 +0200 [thread overview] Message-ID: <20190424193636.GU9857@phenom.ffwll.local> (raw) In-Reply-To: <20190424185617.16865-2-eric@anholt.net> 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@anholt.net> > Suggested-by: Daniel Vetter <daniel.vetter@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@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 _______________________________________________ dri-devel mailing list dri-devel@lists.freedesktop.org https://lists.freedesktop.org/mailman/listinfo/dri-devel
next prev parent reply other threads:[~2019-04-24 19:36 UTC|newest] Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top 2019-04-24 18:56 [PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next Eric Anholt 2019-04-24 18:56 ` [PATCH 2/2] drm/doc: Document expectation that userspace review looks at kernel uAPI Eric Anholt 2019-04-24 19:36 ` Daniel Vetter [this message] 2019-04-24 19:36 ` Daniel Vetter 2019-05-21 7:47 ` Pekka Paalanen 2019-05-21 7:47 ` Pekka Paalanen 2019-05-21 8:26 ` Daniel Vetter 2019-04-24 19:35 ` [PATCH 1/2] drm/doc: Allow new UAPI to be used once it's in the driver's -next Daniel Vetter 2019-04-24 20:16 ` Dave Airlie 2019-04-24 22:06 ` [PATCH 1/2 v2] drm/doc: Allow new UAPI to be used once it's in drm-next/drm-misc-next Eric Anholt 2019-04-25 6:33 ` Daniel Vetter 2019-05-16 16:38 ` Eric Anholt
Reply instructions: You may reply publicly to this message via plain-text email using any one of the following methods: * Save the following mbox file, import it into your mail client, and reply-to-all from there: mbox Avoid top-posting and favor interleaved quoting: https://en.wikipedia.org/wiki/Posting_style#Interleaved_style * Reply using the --to, --cc, and --in-reply-to switches of git-send-email(1): git send-email \ --in-reply-to=20190424193636.GU9857@phenom.ffwll.local \ --to=daniel@ffwll.ch \ --cc=airlied@gmail.com \ --cc=daniel.vetter@ffwll.ch \ --cc=dri-devel@lists.freedesktop.org \ --cc=eric@anholt.net \ --cc=linux-kernel@vger.kernel.org \ /path/to/YOUR_REPLY https://kernel.org/pub/software/scm/git/docs/git-send-email.html * If your mail client supports setting the In-Reply-To header via mailto: links, try the mailto: linkBe sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.