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
| ||
|
Date: Wed, 04 Oct 2017 17:18:04 -0300 From: Gustavo Padovan <gustavo.padovan@...labora.com> To: Brian Starkey <brian.starkey@....com>, Gustavo Padovan <gustavo@...ovan.org> Cc: linux-media@...r.kernel.org, Hans Verkuil <hverkuil@...all.nl>, Mauro Carvalho Chehab <mchehab@....samsung.com>, Shuah Khan <shuahkh@....samsung.com>, linux-kernel@...r.kernel.org, Jonathan.Chai@....com Subject: Re: [PATCH v3 10/15] [media] vb2: add 'ordered' property to queues On Mon, 2017-10-02 at 14:43 +0100, Brian Starkey wrote: > Hi, > > On Thu, Sep 07, 2017 at 03:42:21PM -0300, Gustavo Padovan wrote: > > From: Gustavo Padovan <gustavo.padovan@...labora.com> > > > > For explicit synchronization (and soon for HAL3/Request API) we > > need > > the v4l2-driver to guarantee the ordering in which the buffers were > > queued > > by userspace. This is already true for many drivers, but we never > > needed > > to say it. > > > > Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.com> > > --- > > include/media/videobuf2-core.h | 4 ++++ > > 1 file changed, 4 insertions(+) > > > > diff --git a/include/media/videobuf2-core.h > > b/include/media/videobuf2-core.h > > index 5ed8d3402474..20099dc22f26 100644 > > --- a/include/media/videobuf2-core.h > > +++ b/include/media/videobuf2-core.h > > @@ -508,6 +508,9 @@ struct vb2_buf_ops { > > * @last_buffer_dequeued: used in poll() and DQBUF to immediately > > return if the > > * last decoded buffer was already dequeued. Set for > > capture queues > > * when a buffer with the V4L2_BUF_FLAG_LAST is > > dequeued. > > + * @ordered: if the driver can guarantee that the queue will be > > ordered or not. > > + * The default is not ordered unless the driver > > sets this flag. It > > + * is mandatory for using explicit fences. > > If it's mandatory for fences (why is that?), then I guess this patch > should come before any of the fence implementation? As of this implementation it is mandatory for out-fences, so that is why I didn't put it before the in-fences support. > > But it's not entirely clear to me what this flag means - ordered with > respect to what? Ordered such that the order in which the buffers are > queued in the driver are the same order that they will be dequeued by > userspace? Exactly. > I think the order they are queued from userspace can still be > different from both the order they are queued in the driver (because > the in-fences can signal in any order), and dequeued again in > userspace, so "ordered" seems a bit ambiguous. Exactly. That is what the current implementation does. > > I think it should be more clear. Sure, sorry for not being clear, the next iteration will have a much better explanation. Gustavo
Powered by blists - more mailing lists