Re: For review: pid_namespaces(7) man page

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



On 03/03/2013 10:03:55 PM, Eric W. Biederman wrote:
Rob Landley <rob@xxxxxxxxxxx> writes:

> On 03/01/2013 03:57:40 AM, Michael Kerrisk (man-pages) wrote:
>> > And yet the glibc guys insist on #define
>> GNU_GNU_GNU_ALL_HAIL_STALLMAN in
>> > order to access this Linux-specific feature which has nothing
>> whatsoever to
>> > do with the FSF.
>>
>> This is a misunderstanding. _GNU_SOURCE is the standard way to expose
>> Linux-specific functionality from POSIX header files.
>
> What standard? The Linux kernel is not, and never was, part of the GNU
> project.

Is the argument that there should be a _LINUX_SOURCE directive in glibc
for this?

If you don't #define any feature test macros at all, you get a bunch of macros (_BSD_SOURCE, _SVID_SOURCE, _POSIX_SOURCE, _POSIX_C_SOURCE=200809L, and so on) defined by default in features.h. If you start defining macros, several of the default ones _go_away_, and you start missing things that are defined by posix-2008. Yes, defining feature test macros makes definitions _vanish_ out of the headers, which means feature test macros can actually reduce code portability.

The _GNU_SOURCE is glibc's way of saying "switch on everything glibc offers". (Except it isn't _quite_, but that seems to be what they intended.) So there are various things that test _specifically_ for that macro, but the macro also switches on (from features.h):

/* If _GNU_SOURCE was defined by the user, turn on all the other features. */
#ifdef _GNU_SOURCE
# undef  _ISOC95_SOURCE
# define _ISOC95_SOURCE 1
# undef  _ISOC99_SOURCE
# define _ISOC99_SOURCE 1
# undef  _POSIX_SOURCE
# define _POSIX_SOURCE  1
# undef  _POSIX_C_SOURCE
# define _POSIX_C_SOURCE        200809L
# undef  _XOPEN_SOURCE
# define _XOPEN_SOURCE  700
# undef  _XOPEN_SOURCE_EXTENDED
# define _XOPEN_SOURCE_EXTENDED 1
# undef  _LARGEFILE64_SOURCE
# define _LARGEFILE64_SOURCE    1
# undef  _BSD_SOURCE
# define _BSD_SOURCE    1
# undef  _SVID_SOURCE
# define _SVID_SOURCE   1
# undef  _ATFILE_SOURCE
# define _ATFILE_SOURCE 1
#endif

This is not fine-grained control of what libc exports. This is "if you want to use unshare() then everything we ever implemented gets simultaneously exported into your namespace". (Which it _mostly_ is if you never use any feature test macros, but not the Linux-specific system calls.)

The new musl-libc.org did an _ALL_SOURCE macro that just enables every feature test macro they implemented. (That's its definition, it's the feature test macro that says feature test macros area bad idea.)

Although come to think of it I can't imagine how <sched.h> is a POSIX
header.  Last I looked it only had linux specific bits in it.  Which
makes needing any kind of #define strange.

My objection is that Linux system calls are not part of the GNU project. Requiring that macro to get Linux system calls out of bionic, uClibc, klibc, musl, olibc, dietlibc, or newlib is _silly_. It's the "GNU/Linux" prefix imposed on the source level, and it's a fairly recent development (I've only noticed it since 2008 or so).

Rob--
To unsubscribe from this list: send the line "unsubscribe linux-man" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at  http://vger.kernel.org/majordomo-info.html


[Index of Archives]     [Kernel Documentation]     [Netdev]     [Linux Ethernet Bridging]     [Linux Wireless]     [Kernel Newbies]     [Security]     [Linux for Hams]     [Netfilter]     [Bugtraq]     [Yosemite News]     [MIPS Linux]     [ARM Linux]     [Linux RAID]     [Linux Admin]     [Samba]

  Powered by Linux