Am 20.08.2016 um 19:58 schrieb Mikko Rapeli: > 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?
libdrm has a whole bunch of unit tests exercising the kernel UAPI headers for both API and ABI compatibility. So to be honest I see your good intentions here, but no those checks are completely useless for us. Christian. > 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. > > Yes, there have been some regressions in this work but to err is human. > What is the actual problem and how can we (yes, including me) try to > solve it? > > -Mikko
