On Mon, Aug 22, 2016 at 4:48 AM, Emil Velikov <emil.l.velikov@xxxxxxxxx> wrote: > On 20 August 2016 at 23:31, Rob Clark <robdclark@xxxxxxxxx> wrote: >> On Sat, Aug 20, 2016 at 1:58 PM, Mikko Rapeli <mikko.rapeli@xxxxxx> 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
