Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1467473

[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>")

Show all headers | View raw

On 20 August 2016 at 23:31, Rob Clark <robdclark@gmail.com> wrote:
> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli <mikko.rapeli@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.

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.

Thanks
Emil

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

Back to linux.kernel | Previous | Next — Next in thread | Find similar | Unroll thread

Thread

[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>") Emil Velikov <emil.l.velikov@gmail.com> - 2016-08-22 10:50 +0200
  Re: [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>") Christian König <deathsimple@vodafone.de> - 2016-08-22 11:00 +0200
  Re: [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>") Mikko Rapeli <mikko.rapeli@iki.fi> - 2016-08-22 12:30 +0200
  Re: [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 <robdclark@gmail.com> - 2016-08-22 12:40 +0200
    Re: [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>") Daniel Vetter <daniel@ffwll.ch> - 2016-08-22 16:40 +0200
      Re: [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>") Emil Velikov <emil.l.velikov@gmail.com> - 2016-08-22 17:10 +0200
        Re: [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>") Daniel Vetter <daniel@ffwll.ch> - 2016-08-22 17:50 +0200
  Re: [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>") randyf@sibernet.com - 2016-08-22 23:30 +0200

csiph-web