linux-kernel - Re: using kernel headers in libc headers

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: Windows password security audit tool. GUI, reports in PDF.

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

Message-ID: <4B13FA4E.1070901@zytor.com>
Date:	Mon, 30 Nov 2009 09:01:02 -0800
From:	"H. Peter Anvin" <hpa@...or.com>
To:	Ulrich Drepper <drepper@...il.com>
CC:	Linux Kernel Mailing List <linux-kernel@...r.kernel.org>,
	Linus Torvalds <torvalds@...ux-foundation.org>
Subject: Re: using kernel headers in libc headers

On 11/30/2009 08:37 AM, Ulrich Drepper wrote:
> 
> It's likely in everybody's interest to get the kernel headers used.
> But for this mode #ifdefs are needed.  I'm willing to do the work.
> Easy enough to do when I'm going through the headers one-by-one to
> enable them in glibc.  But I don't want to start this work unless it's
> going to be accepted.  The symbols would be something like
> 
>   __USE_MISC
> 
> or
> 
>   __USE_GNU
> 
> These are not macros which the user must define.  The user sets macros
> like _GNU_SOURCE etc which then set all the appropriate __USE_* macros
> (see "info libc 'Feature Test Macros'" on machines with glibc
> installed).  These names are somewhat glibc-specific but other libcs
> can (or already have) adapt them.
> 
> So, what do you say?

Speaking for myself, I think #ifdefs utterly suck for this purpose.
First of all, because they tie back a glibc internal (the naming of
feature test macros) with the kernel headers.  Second of all, because it
really makes it much harder to get things right.  Third, because it
conflicts with the usage model in the kernel itself in a way that is
likely to cause breakage.

A better way is to factor out subsets; if <linux/sched.h> has too many
things, we can break out the POSIX parts into <linux/sched_posix.h> or
(certainly better if we have more than one of these)
<linux/sched/posix.h> which can also be included by <linux/sched.h>.

glibc can then choose to include or not include <linux/sched/posix.h>
depending on its configuration.  The configuration macros remain a glibc
internal detail.

	-hpa

-- 
H. Peter Anvin, Intel Open Source Technology Center
I work for Intel.  I don't speak on their behalf.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Please read the FAQ at  http://www.tux.org/lkml/