Re: [PATCH v2 01/11] dma-buf/sync_file: de-stage sync_file

[Greg Hackmann <ghackmann@google.com>]

On 01/28/16 01:23, Daniel Vetter wrote:
> And I think driver_data really shouldn't be there, it makes things
> complicated with the array of variable-sized objects, and generic
> userspace can't really use it - for debug output we already have
> obj/driver_name per fence point, which I think is good enough.

I looked at our device kernels, and some vendors actually are filling in 
driver_data.  I'm just not seeing any accesses to them in our 
*userspace* tree.  And in a lot of cases it looks like they're just 
filling in debugging information that they could get elsewhere.

I'm checking with our vendor contacts to see what they're actually using 
this for (if anything).

> Would that be ok for you from the Android side if Gustavo also provides a
> patch to update libsync? I don't think the ABI is fundamentally broken,
> but this light cleanup would be nice.

No objections here.  Just upload the changes to AOSP and add me as a 
reviewer.

> Wrt keeping SYNC_WAIT: I think that's totally fine. Redundant since
> polling is supported, but not really an issue imo either. If we're totally
> lazy we could implement SYNC_WAIT internally using poll and shave off a
> few lines of the implementation.

Honestly this is the change I'm least worried about, since poll() will 
work with existing kernels too.  The only difference would be that the 
SYNC_WAIT ioctl fails when given something that's not specifically a 
sync fence; but I'm skeptical that anything actually depends on that 
behavior.