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. 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 _______________________________________________ dri-devel mailing list dri-devel@xxxxxxxxxxxxxxxxxxxxx https://lists.freedesktop.org/mailman/listinfo/dri-devel
