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.
_______________________________________________ devel mailing list devel@xxxxxxxxxxxxxxxxxxxxxx http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
