This is the mail archive of the
mailing list for the glibc project.
Re: [PATCH v2 1/2] Add framework for tunables
- From: Siddhesh Poyarekar <sid at reserved-bit dot com>
- To: Florian Weimer <fweimer at redhat dot com>
- Cc: libc-alpha at sourceware dot org, roland at hack dot frob dot com, carlos at redhat dot com, Andi Kleen <andi at firstfloor dot org>, tuliom at linux dot vnet dot ibm dot com, "Paul E. Murphy" <murphyp at linux dot vnet dot ibm dot com>, munroesj at linux dot vnet dot ibm dot com
- Date: Sun, 14 Feb 2016 10:17:13 +0530
- Subject: Re: [PATCH v2 1/2] Add framework for tunables
- Authentication-results: sourceware.org; auth=none
- References: <20160116185545 dot GA17772 at devel dot intra dot reserved-bit dot com> <56BB3D99 dot 1010401 at redhat dot com>
On Wed, Feb 10, 2016 at 02:39:37PM +0100, Florian Weimer wrote:
> I think it is a mid-term goal to support re-tuning of running processes
> (from the outside). It seems difficult to get there from what you have
> posted, mainly for two reasons:
In general getting to re-tuning running processes will require
significant changes anyway and I don't want to over-engineer the
current solution based on that target. Of course, if you have an idea
that doesn't need too much additional infrastructure then I am very
interested in hearing that.
> Tunable arguments are strings. It is difficult patch strings into
> running processes because of memory management issues (when is it safe
> to free the old version?), and you'd have to call the registered
> callback to parse.
<see comment about self-description>
> Tunables are registered programmatically. This means that there is a
> time where the tunables descriptor information is incomplete and only
> partially initialized. The introspecting process would have to
> compensate for this rare corner case.
The introspecting process will have to synchronize with the target in
some other way. That would be a necessary enhancement regardless of
the way the data is represented.
> Furthermore, the tunables in glibc should be self-describing, but they
> currently are not because there is no type information associated with
> them, and it is not possible to determine the valid number ranges.
I had done an initial mockup with self-describing tunables but I don't
remember why I had dropped it. Maybe I could try it again and see if
I come across the problem again. That should also fix the string
> A declarative approach would also avoid a discussion whether we have to
> mangle function pointers (because there wouldn't be any).
> > + const char *name = envvars[i].env;
> > + char *ename = alloca (len + 1);
> Looks like an unbounded alloca, and it's in a loop even.
It is bounded by the length of the tunable name, which is specified in
the glibc source.