[PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>"

[Emil Velikov]

On 19 August 2016 at 15:26, Christian König <deathsimple at vodafone.de> wrote:
> Am 19.08.2016 um 15:50 schrieb Marek Olšák:
>>
>> From: Marek Olšák <marek.olsak at amd.com>
>>
>> This reverts commit 2ce9dde0d47f2f94ab25c73a30596a7328bcdf1f.
>>
>> See the comment in the code. Basically, don't do cleanups in this header.
>>
>> Signed-off-by: Marek Olšák <marek.olsak at amd.com>
>
>
> I completely agree with you that this was a bad move, but I fear that we
> will run into opposition with that.
>
Please check the facts before introducing RATHER ANNOYING AND HARD TO
READ COMMENT IN ALL CAPS.

Story time:
I was dreaming of a day were we can stop installing these headers,
thus making deprecation a bit easier process.
Yet after failing to convince Dave and Daniel on a number of occasions
I've accepted that those headers _are_ here to stay. And yes they
_are_ the UAPI, even though no applications are meant to use them but
the libdrm 'version'.
Thus any changes to the libdrm ones should be a mirror of the ones
here and libdrm should _not_ differ.

But let's ignore all that and imagine that those headers are _not_
UAPI. That gives us even greater reason to _not_ use the uintx_t types
but the kernel __uX ones. The series that did these changes had a fair
few references why we want that.

Yes, I can imagine that the situation isn't ideal, and/or not that
clear. Then again a check with git log should have straightened things
out.
If not _please_ help us improve this (documentation and/or others).


And last but not least, please share with up what inspired this -
(build/runtime) regression, attempted sync with libdrm, other ?

Thanks
Emil