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
| ||
|
Date: Sun, 21 Aug 2016 11:03:21 +0200 From: Christian König <deathsimple@...afone.de> To: Mikko Rapeli <mikko.rapeli@....fi>, Emil Velikov <emil.l.velikov@...il.com> Cc: Marek Olšák <maraeo@...il.com>, ML dri-devel <dri-devel@...ts.freedesktop.org>, linux-kernel@...r.kernel.org Subject: Re: [PATCH 1/2] Revert "include/uapi/drm/amdgpu_drm.h: use __u32 and __u64 from <linux/types.h>" 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
Powered by blists - more mailing lists