Op 04-02-16 om 14:05 schreef Gustavo Padovan:
> 2016-02-04 Maarten Lankhorst <[email protected]>:
>
>> Op 03-02-16 om 21:09 schreef Gustavo Padovan:
>>> Hi Maarten,
>>>
>>> 2016-02-03 Maarten Lankhorst <[email protected]>:
>>>
>>>> Op 03-02-16 om 14:25 schreef Gustavo Padovan:
>>>>> From: Gustavo Padovan <[email protected]>
>>>>>
>>>>> Turn sync_fence_info into __u64 type enable us to extend the struct in the
>>>>> future without breaking the ABI.
>>>>>
>>>>> v2: use type __u64 for fence_info
>>>>>
>>>>> v3: fix commit message to reflect the v2 change
>>>>>
>>>>> Signed-off-by: Gustavo Padovan <[email protected]>
>>>>> ---
>>>>> drivers/staging/android/sync.c | 2 +-
>>>>> drivers/staging/android/uapi/sync.h | 2 +-
>>>>> 2 files changed, 2 insertions(+), 2 deletions(-)
>>>>>
>>>>> diff --git a/drivers/staging/android/sync.c
>>>>> b/drivers/staging/android/sync.c
>>>>> index 2ab0c20..8425457 100644
>>>>> --- a/drivers/staging/android/sync.c
>>>>> +++ b/drivers/staging/android/sync.c
>>>>> @@ -525,7 +525,7 @@ static long sync_file_ioctl_fence_info(struct
>>>>> sync_file *sync_file,
>>>>> if (info->status >= 0)
>>>>> info->status = !info->status;
>>>>>
>>>>> - len = sizeof(struct sync_file_info);
>>>>> + len = sizeof(struct sync_file_info) - sizeof(__u64);
>>>>>
>>>>> for (i = 0; i < sync_file->num_fences; ++i) {
>>>>> struct fence *fence = sync_file->cbs[i].fence;
>>>>> diff --git a/drivers/staging/android/uapi/sync.h
>>>>> b/drivers/staging/android/uapi/sync.h
>>>>> index a0cf357..e649953 100644
>>>>> --- a/drivers/staging/android/uapi/sync.h
>>>>> +++ b/drivers/staging/android/uapi/sync.h
>>>>> @@ -54,7 +54,7 @@ struct sync_file_info {
>>>>> char name[32];
>>>>> __s32 status;
>>>>>
>>>>> - __u8 sync_fence_info[0];
>>>>> + __u64 sync_fence_info;
>>>>> };
>>>>>
>>>>> #define SYNC_IOC_MAGIC '>'
>>>> This still doesn't do what you expect it to.
>>>>
>>>> I think this is what you want is for userspace to do:
>>>>
>>>> struct sync_file_info info;
>>>>
>>>> info.flags = info.num_fences = 0;
>>>> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
>>>> if (info.num_fences) {
>>>> info.sync_fence_info = (uintptr)kcalloc(info.num_fences, sizeof(struct
>>>> sync_fence_info));
>>>> ioctl(fd, SYNC_IOC_FENCE_INFO, &info);
>>>> }
>>>>
>>>> Maybe userspace could preallocate the max in advance and set num_fences
>>>> higher,
>>>>
>>>> kernel would do something like:
>>>>
>>>> num_fences = min(info.num_fences, sync->num_fences);
>>>> struct sync_fence_info array[num_fences];
>>>>
>>>> info.num_fences = sync->num_fences;
>>>> if (num_fences &&
>>>> copy_to_user((void * __user)(unsigned long)info.sync_fence_info,
>>>> array, num_fences * sizeof(array)))
>>>> return -EFAULT;
>>> If we are going to call IOCTL twice I would actually have a new IOCTL only
>>> to fetch sync_fence_info.
>>>
>>> First we would call
>>>
>>> ioctl(fd, SYNC_IOC_FILE_INFO, &info);
>>>
>>> where info is:
>>>
>>> struct sync_file_info {
>>> char name[32];
>>> __s32 status;
>>> __u32 flags;
>>> __u32 num_fences;
>>> };
>>>
>>> then we would allocate a buffer with
>>>
>>> size = info.num_fences * sizeof(struct sync_fence_info)
>>>
>>> and call the new ioctl
>>>
>>> ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);
>>>
>>> This looks like a cleaner solution and doesn't break ABI. What do you
>>> think?
>> I think it's good taste that userspace specifies the size of the buffer it
>> passes, so former feels more clean to me,
>> since you need to pass num_fences anyway.
> Just to clarify, userspace specifies the size of the buffer in the
> solution I proposed. It would be
>
> size = info.num_fences * sizeof(struct sync_fence_info)
>
> sync_fence_info = malloc(size);
>
> ioctl(fd, SYNC_IOC_SYNC_FENCE_INFO, sync_fence_info);
>
For someone writing a wrapper like valgrind would mean having prior knowledge
of previous ioctl results too.
Hence you would need something like
struct fence_collection {
u32 num_fences;
u32 pad;
struct sync_fence_info fences[0];
}
in which case you might as well return it optionally as a pointer in
sync_file_info.
~Maarten
_______________________________________________
devel mailing list
[email protected]
http://driverdev.linuxdriverproject.org/mailman/listinfo/driverdev-devel
