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

[randyf at sibernet.com]

On Mon, 22 Aug 2016, Daniel Vetter wrote:

> On Sat, Aug 20, 2016 at 8:58 PM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>
>> All I can think of is that you (?) are porting some changes from the
>> kernel to libdrm or vice-versa. In the latter case please _don't_ do
>> that. Work with your changes in upstream kernel, then pull them down
>> to libdrm with `make headers_install`.
>
> Same here, I'm honestly not clear on what the problem is. uapi flows
> from the kernel, we _must_ change the kernel headers first before
> libdrm, and we can do that as long as we don't change the api or abi.

   IMO, the problem is that they can be different.  And any difference is 
an opportunity for problems.  It wouldn't matter which is the master, so 
long both sides consume the same file.

>
> Resyncing is trivial using make headers_install and the flow Emil laid
> out. Definitely _never_ apply uapi changes to libdrm first (or only,
> and iirc one of the radeon headers had done that).
> -Daniel

   In the Solaris space, there isn't a 'make headers_install' that is 
sufficient to resolve the discrepancy (the uapi files are not usable as 
is and need patching - might be the same for the BSD's as well).  So this 
methodology might be sufficient for Linux, but will in some way fall short 
for others (yes, I am aware of this and take it on, but occasionally nice 
to note).


   Cheers!


 	---- Randy