Hi Christian,

On 09/16/2016 06:49 PM, Christian König wrote:
> NAK, that is clearly an API breakage.

It should have never been typedef'ed in the first place. Does that mean
we would have to bump version for API change? What is the procedure there?

> 
> BTW: Why would we want to stop hiding the type?

Quite a few reasons, I'll start with to justify the change:

https://git.kernel.org/cgit/linux/kernel/git/torvalds/linux.git/tree/Documentation/CodingStyle?id=refs/tags/v4.8-rc6#n276

Suppose you have 'amdgpu_semaphore_handle' as typedef of a pointer type
and you had some function 'void f(amdgpu_semaphore_handle * h) {}'.
Suppose now, within 'f()' we deference 'h' and use the result in some
way. The issue is that it is not directly obvious that we have a double
pointer type and so while it maybe the case that '(*h != NULL)' it could
well be the case that '(h == NULL)'.

Kind Regards,
Edward.

> 
> Christian.
> 
> Am 16.09.2016 um 10:46 schrieb Edward O'Callaghan:
>> Oops, turns out I mailed to dri-devel by mistake so resending here.
>>
>> The following series fixes up libdrm/amdgpu such that to not hide
>> a pointer type behind a typedef.
>>
>> Please Review,
>>
>> Edward O'Callaghan (3):
>>   [PATCH 1/3] amdgpu: Fix amdgpu_va_handle typedef not to hide pointer
>>   [PATCH 2/3] amdgpu: Fix amdgpu_semaphore_handle typedef not to hide
>>   [PATCH 3/3] amdgpu: Fix amdgpu_bo_list_handle typedef not to hide
>> _______________________________________________
>> amd-gfx mailing list
>> amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
> 
>