This is the mail archive of the libc-alpha@sourceware.org mailing list for the glibc project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]
Other format: [Raw text]

Re: Env var to tunable mapping?


On 09/02/2015 12:33 PM, Carlos O'Donell wrote:
> On 08/19/2015 01:41 PM, Siddhesh Poyarekar wrote:
>> On Wed, Aug 19, 2015 at 11:24:39AM -0500, Paul E. Murphy wrote:
>>> As Siddhesh notes, there are already quite a few env variables which alter
>>> the behavior of libc and company. He does a good job of describing
>>> the requirements of such a framework. I see no reason why it can't
>>> be approached incrementally.
>>
>> It will in fact be approached incrementally.  I have patches on the
>> siddhesh/tunables branch that I need to fix up following our
>> discussion at the GNU Tools Cauldron and post on the list.  I hope to
>> be able to do it before the end of the week.
>>
>>> Adding to the requirements, would a common syntax for tunable environment
>>> variables be desirable?
>>
>> The namespace requirements are frozen, but the open question currently
>> is how we read values for those tunable names.  My initial draft made
>> environment variables out of those names, but the consensus in the
>> room last week leaned towards an alternate expression, perhaps a
>> single environment variable with a string value that is parsed to get
>> all tunable values.  There could be other ideas, I'll think about it
>> once I get the initial framework in.
> 
> To be clear it was Roland McGrath who supported the position that we have
> a single env var for all tunables. I heard no other opinions for this case.
> 
> I do not support that position. I posit we should have one tunable per env
> var, and that we should follow namespace rules for those env vars e.g.
> always start with GLIBC_*. There is precedent for this, the Gnome xdg-app
> framework is already exporting XDG_* env vars in a sensible namespace, and
> as a framework just above us, they already have to deal with this kind of
> pseudo-API.

I'd prefer multiple env vars. It may also give extra flexibility when parsing
them.

> You can argue that unsetting all tunables is harder. It is.
> 
> Instead of:
> unset GLIBC_TUNABLES
> 
> You have to:
> env | while read env; do if [[ $env == GLIBC* ]]; then unset $env; fi; done;
> 
> But what's the more probable case? I would argue it's more probably that you
> want to set or unset just one tunable. Having them all in one string is therefore
> more complicated and requires special shell set and unset functions to assist.
> 
> If we start off on the right foot, and document that all GLIBC_* env vars need
> to be unset if you want default behaviour, then people will listen, and they
> will follow. Better yet we talk to Michael Kerrisk and get it documented in
> the man pages early how to set or unset the tunables.
> 
> More people have to speak up about which interface they would like to see.
> 
> Cheers,
> Carlos.
> 


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]