[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <56A8D4A7.1070409@linux.intel.com>
Date: Wed, 27 Jan 2016 15:31:03 +0100
From: Maarten Lankhorst <maarten.lankhorst@...ux.intel.com>
To: Gustavo Padovan <gustavo@...ovan.org>,
Greg Kroah-Hartman <gregkh@...uxfoundation.org>
Cc: linux-kernel@...r.kernel.org, devel@...verdev.osuosl.org,
dri-devel@...ts.freedesktop.org,
Daniel Stone <daniels@...labora.com>,
Arve Hjønnevåg <arve@...roid.com>,
Riley Andrews <riandrews@...roid.com>,
Daniel Vetter <daniel.vetter@...ll.ch>,
Rob Clark <robdclark@...il.com>,
Greg Hackmann <ghackmann@...gle.com>,
John Harrison <John.C.Harrison@...el.com>,
Gustavo Padovan <gustavo.padovan@...labora.co.uk>
Subject: Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file
Hey,
Op 27-01-16 om 14:30 schreef Gustavo Padovan:
> From: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>
> sync_file is useful to connect one or more fences to the file. The file is
> used by userspace to track fences.
>
> Signed-off-by: Gustavo Padovan <gustavo.padovan@...labora.co.uk>
>
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
Looking at the patch, it seems you kept SYNC_IOC_WAIT, won't it be better to remove it, and only support waiting with polling?
The code for polling should already work.
It's very unclear what format @driver_data has. I kept it for compatibility with android, but it's not clear to me how a userspace consumer would print it.
Is there a usecase for this, or could it be removed from fence and sync_file?
~Maarten
Powered by blists - more mailing lists