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

["Christian König" <deathsimple@vodafone.de>]

Am 20.08.2016 um 19:58 schrieb Mikko Rapeli:
> Cc'ing lkml too.
>
> On Fri, Aug 19, 2016 at 11:54:21PM +0100, Emil Velikov wrote:
>> 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.
> Another day dream:
>
> Wouldn't it be nice if the uapi headers from Linux kernel would pass
> a simple quality check of compiling in userspace where they are meant to be
> used?

libdrm has a whole bunch of unit tests exercising the kernel UAPI 
headers for both API and ABI compatibility.

So to be honest I see your good intentions here, but no those checks are 
completely useless for us.

Christian.

>   Stand alone. Without magic tricks and additional libraries and their
> headers. Without glibc or any other libc implementation specific additions.
> The uapi headers define many parts of the Linux kernel API and ABI, and thus
> compiling them also without the 'official' GNU/Linux userspace libraries
> like glibc or libdrm does have some uses. For example API and ABI
> compatibility checks and API/ABI/system call fuzzers.
>
> Many headers required stdint.h types but Linux kernel headers do not
> define them in userspace, and then Linus has said that uapi headers
> should use the linux/types.h with double underscores. Thus my patches
> for fixing trivial compile errors turned into changing several stdint.h
> definitions to linux/types.h.
>
> Yes, there have been some regressions in this work but to err is human.
> What is the actual problem and how can we (yes, including me) try to
> solve it?
>
> -Mikko