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?


----- Original Message -----
> I think one can make an objective case for going either way, but it
> strikes me as
> simpler in the long run to do separate environment variables.  Special syntax
> always tends to seem plenty powerful in the beginning, then a couple years
> later
> it's "who thought this made sense??", and then after that, someone comes
> up with a use case for which the special syntax does not work well, and then
> you're roped into lots of syntax-grafting hackery.
> 
> With multiple env vars, the fancy new tunable of 2020 can have its own
> distinctive
> syntax if necessary, no trying to fit into what seemed clever in 2015.

What kind of a fancy tunable do you foresee?  A struct that is filled in using
a formatted string value?  That should not matter to the framework at all since
the headache of parsing the string value and interpreting the actual value is
passed on to the setter function.

The tunable framework should only be concerned with string-based name-value
pairs.  Anything more complicated and I'd say we're trying to do too much. The
question then is whether those name-value pairs are individual environment
variables and their values or a single environment variable with a space
separated list of name-value pairs.

Siddhesh


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