On 01/27/2016 12:25 PM, Gustavo Padovan wrote:
Is there a value in keeping the abi unchanged?
If not, then Documentation/ioctl/botching-up-ioctls.txt is worth a read.
None from me. I'll look where we can improve the ABI.
Android has existing clients of the current ABI. Thankfully they're all
contained in system services like SurfaceFlinger, since end-user apps
don't get direct access to fence fds.
As long the ABI breaks don't remove functionality we depend on, we can
wrap around them in our userspace libsync. I'd rather not have to do
that, but it's a price I'm willing to pay to get this moved out of staging.
- struct sync_file_info_data::fence_info is of type __u8 yet it is "a
fence_info struct for every fence in the sync_file". Thus shouldn't
one use "struct fence_info" as the type ?
Agreed. But I'm currently thinking if we really should keep this ioctl.
Gustavo
I'm not seeing any consumers of driver_data in our tree. OTOH
completely getting rid of the ioctl would be a problem, since
SurfaceFlinger depends on the timestamp information for its own bookkeeping.
_______________________________________________
devel mailing list
devel@xxxxxxxxxxxxxxxxxxxxxx
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
