[RFC] Using C99 stdint vs kernel __uX types in kernel drmUAPI (was Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>")

[Rob Clark]

On Mon, Aug 22, 2016 at 4:48 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
> On 20 August 2016 at 23:31, Rob Clark <robdclark at gmail.com> wrote:
>> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli <mikko.rapeli at iki.fi> wrote:
>>> 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? 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.
>>
>> The problem is, for the most part, the driver specific gpu related
>> ioctl interfaces are not intended for general public consumption.
>> They have one consumer, ie. libdrm_$drivername (or perhaps mesa
>> directly).  They are complex interfaces, because GPUs are complex.
>> They are not intended to be used directly (or for the most part, even
>> indirectly) by random userspace applications.  And in fact the uapi
>> headers exported from kernel are not actually ever used.  (ie.
>> libdrm_$drivername uses it's own copy internally within libdrm.)
>>
>> So Linus's argument against stdint types, as weak as it is, doesn't
>> even apply for gpu driver specific ioctls.
>>
> Although last time around people leaned towards the __uX types, if we
> have a consensus amongst drm (kernel) developers about using stdint
> ones everything should be fine.
> We just need a handful of acks from the different maintainers.

maybe I didn't grumble loudly enough at the time (against __uX types)

> That said, _note_ that some applications are built with -C89 -pedantic
> [1] which means that using stdint.h may or may not work as expected.
> So we'll want a __STDC_VESION__ check + #error in case of pre-C99 ?
> If the affected programs are proprietary ones we should be safe,
> otherwise we want to update them ~alongside the transition.

naw, at least for msm_drm.h, just don't build libdrm_freedreno w/
-C89.. problem solved!

BR,
-R

> Thanks
> Emil
>
> [1]
> https://cgit.freedesktop.org/mesa/drm/commit/?id=0f4452bb51306024fbf4cbf77d8baab20cefba67
> https://cgit.freedesktop.org/mesa/drm/commit/?id=d20314d083e533e3b8753192b1846752341afbbe