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
