[PATCH 5/8] sync_file: add support for a semaphore object

[Chris Wilson]

On Thu, Apr 13, 2017 at 05:05:27AM +1000, Dave Airlie wrote:
> >>
> >> Not sure what the best semantics are there, any opinions on barring
> >> wakeups/polling on semaphore sync_files, and just punting this
> >> until we need it.
> >
> > I think getting it right now will make writing sw_sync-esque (i.e. cpu)
> > tests easier and more complete.
> 
> I just don't have any use case for it, so we would be writing code to
> write tests for it.
> 
> That doesn't seem smart.
> 
> If there is a future non-testing use case, the API is expressive
> enough for someone
> to add a flag or new sync obj to allow polling and to add support in a
> nice easily
> digestible patch.

My first thought was to check the signaled status would be to use
poll(0), but that can be retrieved from the sync_file_status ioctl. But
to get that still needs for us to acquire an fd from the syncobj. And if
we were to want check the flag on a driver syncobj, we would need to be
able to export one. That doesn't look very promising...

The testing chain would look like

	create syncobj
	execbuf -> signal syncobj
	syncobj wait -> dummy/nop execbuf -> fence out

then use the fence as a proxy for testing the status of the syncobj.

For generic tests, we could add an interface for vgem to use syncobjs?

If there's no way to export an fd for the syncobj, then we don't need
to handle it in the fops. Just be sure to leave a breadcrumb behind so
that the first person who does try to pass back a syncobj fd is reminded
that they need to fill in the fops.
-Chris

-- 
Chris Wilson, Intel Open Source Technology Centre