All of lore.kernel.org
 help / color / mirror / Atom feed
From: "Christian König" <deathsimple-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
To: Edward O'Callaghan
	<funfunctor-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org>,
	amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org
Subject: Re: libdrm/amdgpu - Fixup typedef not to hide pointer type
Date: Fri, 16 Sep 2016 12:49:44 +0200	[thread overview]
Message-ID: <84d42cca-25c9-2349-21d8-542dfaa4267c@vodafone.de> (raw)
In-Reply-To: <223e0fa5-bb37-c9d8-9d04-b9ef29d0d9f7-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>

Well thinking more about that what you probably could do is changing the 
typedefs to put the pointer into a single element structure.

That should break only when somebody really abused the API and shouldn't 
change the ABI.

Regards,
Christian.

Am 16.09.2016 um 11:12 schrieb Christian König:
> Am 16.09.2016 um 11:02 schrieb Edward O'Callaghan:
>> 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?
>
> Keep it as it is, you can't change it even if we bump the version 
> number you would break existing userspace.
>
>>
>>> 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 
>>
>
> This doesn't apply here, this is a user space library interface and 
> not the kernel.
>
> The structure types are not defined outside of the library and so you 
> can't dereference or NULL check them.
>
> Regards,
> Christian.
>
>>
>> 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@lists.freedesktop.org
>>>> https://lists.freedesktop.org/mailman/listinfo/amd-gfx
>>>
>

_______________________________________________
amd-gfx mailing list
amd-gfx@lists.freedesktop.org
https://lists.freedesktop.org/mailman/listinfo/amd-gfx

      parent reply	other threads:[~2016-09-16 10:49 UTC|newest]

Thread overview: 8+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2016-09-16  8:46 libdrm/amdgpu - Fixup typedef not to hide pointer type Edward O'Callaghan
     [not found] ` <1474015570-30928-1-git-send-email-funfunctor-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org>
2016-09-16  8:46   ` [PATCH 1/3] amdgpu: Fix amdgpu_va_handle " Edward O'Callaghan
2016-09-16  8:46   ` [PATCH 2/3] amdgpu: Fix amdgpu_semaphore_handle " Edward O'Callaghan
2016-09-16  8:46   ` [PATCH 3/3] amdgpu: Fix amdgpu_bo_list_handle " Edward O'Callaghan
2016-09-16  8:49   ` libdrm/amdgpu - Fixup " Christian König
     [not found]     ` <98564703-e915-2729-b5c9-43afddc881a5-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2016-09-16  9:02       ` Edward O'Callaghan
     [not found]         ` <bc823f27-6163-1688-9cf0-0c8b5934111d-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org>
2016-09-16  9:12           ` Christian König
     [not found]             ` <223e0fa5-bb37-c9d8-9d04-b9ef29d0d9f7-ANTagKRnAhcb1SvskN2V4Q@public.gmane.org>
2016-09-16 10:49               ` Christian König [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=84d42cca-25c9-2349-21d8-542dfaa4267c@vodafone.de \
    --to=deathsimple-antagkrnahcb1svskn2v4q@public.gmane.org \
    --cc=amd-gfx-PD4FTy7X32lNgt0PjOBp9y5qC8QIuHrW@public.gmane.org \
    --cc=funfunctor-dczkZgxz+BNUPWh3PAxdjQ@public.gmane.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.