This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- From: "Carlos O'Donell" <carlos at redhat dot com>
- To: Roland McGrath <roland at hack dot frob dot com>
- Cc: GNU C Library <libc-alpha at sourceware dot org>
- Date: Tue, 8 Sep 2015 23:17:46 -0400
- Subject: Re: Consensus on allowing tunables to use GLIBC_* namespace env vars.
- Authentication-results: sourceware.org; auth=none
- References: <55E90AA9 dot 30909 at redhat dot com> <20150908224050 dot 3EB562C39FE at topped-with-meat dot com>
On 09/08/2015 06:40 PM, Roland McGrath wrote:
> I've previously lodged my general objection to new magic environment variables.
> That's not what this thread is about, so I won't discuss that here.
>
> Talking purely about name spaces of environment variables, I do not think
> that "GLIBC" should be part of any such naming convention. New environment
> variables we add should start with "GNU_", and if we need a name space for
> libc rather than just for GNU, "GNU_LIBC_" or "GNU_PTHREAD_" or suchlike
> are reasonable.
Could you expand a bit on why you think "GLIBC_*" seems unsuitable?
The env vars are project specific, but I guess one could argue that a future
different gnu libc could implement the env vars, and it might be called something
other than glibc. Though it seems unlikely.
I can agree that using "GNU_" is nice, we are a GNU project and that promotes
our GNU-ness. However, in that case I would have consistent naming of "GNU_LIBC_*"
where * expands to all the subsystems and env vars for those subsystems.
What makes you suggest "GNU_PTHREAD_?" Just a shorter name than "GNU_LIBC_PTHREAD_?"
Cheers,
Carlos.