linux-kernel - 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 _

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite for Android: free password hash cracker in your pocket

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:   Mon, 22 Aug 2016 16:38:10 +0200
From:   Daniel Vetter <daniel@...ll.ch>
To:     Rob Clark <robdclark@...il.com>
Cc:     Emil Velikov <emil.l.velikov@...il.com>,
        Mikko Rapeli <mikko.rapeli@....fi>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
        ML dri-devel <dri-devel@...ts.freedesktop.org>
Subject: 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>")

On Mon, Aug 22, 2016 at 12:38 PM, Rob Clark <robdclark@...il.com> wrote:
>> 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!

Yeah, I think sprinkling an

#ifdef __kernel___
#include <linux/types.h>
#else
#include <stdtypes.h>
#endif

at the opt of all drm uapi headers should be good enough. Or at least
those which opt to choose stdints. Since our userspace is very
limited, and our headers will never leak to general applications we
can just require c99, at least for driver headers. For kms/general drm
uapi that might not be the best idea.
-Daniel
-- 
Daniel Vetter
Software Engineer, Intel Corporation
+41 (0) 79 365 57 48 - http://blog.ffwll.ch