[3/4] Enhance --enable-tunables to select tunables frontend at build time
Commit Message
At the GNU Tools Cauldron 2016, the state of the current tunables
patchset was considered OK with the addition of a way to select the
frontend to be used for the tunables. That is, to avoid being locked
in to one type of frontend initially, it should be possible to build
tunables with a different frontend with something as simple as a
configure switch.
To that effect, this patch enhances the --enable-tunables option to
accept more values than just 'yes' or 'no'. The current frontend (and
default when enable-tunables is 'yes') is called 'valstring', to
select the frontend where a single environment variable is set to a
colon-separated value string. More such frontends can be added in
future.
* Makeconfig (have-tunables): Check for non-negative instead
of positive.
* configure.ac: Add 'valstring' as a valid value for
--enable-tunables.
* configure: Regenerate.
* elf/Makefile (have-tunables): Check for non-negative instead
of positive.
(CPPFLAGS-dl-tunables.c): Define TUNABLES_FRONTEND for
dl-tunables.c.
* elf/dl-tunables.c (GLIBC_TUNABLES): Define only when
TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring.
(tunables_strdup): Likewise.
(disable_tunables): Likewise.
(parse_tunables): Likewise.
(__tunables_init): Process GLIBC_TUNABLES envvar only when.
TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring.
* elf/dl-tunables.h (TUNABLES_FRONTEND_valstring): New macro.
(TUNABLES_FRONTEND_yes): New macro, define as
TUNABLES_FRONTEND_valstring by default.
* manual/install.texi: Document new acceptable values for
--enable-tunables.
* INSTALL: Regenerate.
---
INSTALL | 15 ++++++++++++++-
Makeconfig | 4 ++--
configure | 3 ++-
configure.ac | 2 +-
elf/Makefile | 4 +++-
elf/dl-tunables.c | 12 +++++++++++-
elf/dl-tunables.h | 4 ++++
manual/install.texi | 18 +++++++++++++++++-
8 files changed, 54 insertions(+), 8 deletions(-)
Comments
On 11/16/2016 09:35 AM, Siddhesh Poyarekar wrote:
> At the GNU Tools Cauldron 2016, the state of the current tunables
> patchset was considered OK with the addition of a way to select the
> frontend to be used for the tunables. That is, to avoid being locked
> in to one type of frontend initially, it should be possible to build
> tunables with a different frontend with something as simple as a
> configure switch.
>
> To that effect, this patch enhances the --enable-tunables option to
> accept more values than just 'yes' or 'no'. The current frontend (and
> default when enable-tunables is 'yes') is called 'valstring', to
> select the frontend where a single environment variable is set to a
> colon-separated value string. More such frontends can be added in
> future.
I'm not sure if this patch makes sense at this point because without
alternative frontends, it's impossible to tell if the current
initialization sequence is sufficient.
For example, if we want to load a tunable configuration with very low
cost, we could use ldconfig to pre-parse a configuration file and put it
into /etc/ld.so.cache. But we won't know if the current approach works
until this is actually implemented.
Thanks,
Florian
On Tuesday 27 December 2016 05:14 PM, Florian Weimer wrote:
> I'm not sure if this patch makes sense at this point because without
> alternative frontends, it's impossible to tell if the current
> initialization sequence is sufficient.
>
> For example, if we want to load a tunable configuration with very low
> cost, we could use ldconfig to pre-parse a configuration file and put it
> into /etc/ld.so.cache. But we won't know if the current approach works
> until this is actually implemented.
The option --enable-tunables=... doesn't actually do anything beyond
explicitly naming the current tunables frontend implementation. To
write a different frontend, one would not only have to add a new value
to the --enable-tunables=... option but also tweak the current
initialization sequence to suit its frontend without hurting existing
frontends.
I did not intend to make a framework to allow plugging in of different
frontends directly because from the discussions at Cauldron I concluded
that the primary reason for such a requirement was more to loosen the
guarantee of availability of a specific frontend than to allow
co-existence of different frontends at the same time.
Siddhesh
On 12/27/2016 10:10 PM, Siddhesh Poyarekar wrote:
> On Tuesday 27 December 2016 05:14 PM, Florian Weimer wrote:
>> I'm not sure if this patch makes sense at this point because without
>> alternative frontends, it's impossible to tell if the current
>> initialization sequence is sufficient.
>>
>> For example, if we want to load a tunable configuration with very low
>> cost, we could use ldconfig to pre-parse a configuration file and put it
>> into /etc/ld.so.cache. But we won't know if the current approach works
>> until this is actually implemented.
>
> The option --enable-tunables=... doesn't actually do anything beyond
> explicitly naming the current tunables frontend implementation. To
> write a different frontend, one would not only have to add a new value
> to the --enable-tunables=... option but also tweak the current
> initialization sequence to suit its frontend without hurting existing
> frontends.
Okay. I don't know what was decided at the Cauldron because it wasn't
there. The patch doesn't look burdensome going forward, so maybe we can
keep it if it makes someone happy.
Thanks,
Florian
@@ -161,7 +161,20 @@ will be used, and CFLAGS sets optimization options for the compiler.
'--enable-tunables'
Tunables support allows additional library parameters to be
customized at runtime. This is an experimental feature and affects
- startup time and is thus disabled by default.
+ startup time and is thus disabled by default. This option can take
+ the following values:
+
+ * NO This is the default if the option is not passed to
+ configure. This disables tunables.
+
+ * YES This is the default if the option is passed to configure.
+ This enables tunables and selects the default frontend
+ (currently VALSTRING).
+
+ * VALSTRING This enables tunables and selects the VALSTRING
+ frontend for tunables. This frontend allows users to specify
+ tunables as a colon-separated list in a single environment
+ variable GLIBC_TUNABLES.
'--build=BUILD-SYSTEM'
'--host=HOST-SYSTEM'
@@ -884,7 +884,7 @@ CPPFLAGS = $(config-extra-cppflags) $(CPPUNDEFS) $(CPPFLAGS-config) \
$(libof-$(<F)) $(libof-$(@F)),$(CPPFLAGS-$(lib))) \
$(CPPFLAGS-$(<F)) $(CPPFLAGS-$(@F)) $(CPPFLAGS-$(basename $(@F)))
-ifeq (yes,$(have-tunables))
+ifneq (no,$(have-tunables))
CPPFLAGS += -DTOP_NAMESPACE=glibc
endif
@@ -1064,7 +1064,7 @@ endif
# Build the tunables list header early since it could be used by any module in
# glibc.
-ifeq (yes,$(have-tunables))
+ifneq (no,$(have-tunables))
before-compile += $(common-objpfx)dl-tunable-list.h
$(common-objpfx)dl-tunable-list.h: $(..)scripts/gen-tunables.awk \
@@ -1445,7 +1445,8 @@ Optional Features:
--disable-build-nscd disable building and installing the nscd daemon
--disable-nscd library functions will not contact the nscd daemon
--enable-pt_chown Enable building and installing pt_chown
- --enable-tunables Enable tunables support
+ --enable-tunables Enable tunables support. Known values are 'yes',
+ 'no' and 'valstring'
--enable-mathvec Enable building and installing mathvec [default
depends on architecture]
@@ -397,7 +397,7 @@ fi
AC_ARG_ENABLE([tunables],
[AS_HELP_STRING([--enable-tunables],
- [Enable tunables support])],
+ [Enable tunables support. Known values are 'yes', 'no' and 'valstring'])],
[have_tunables=$enableval],
[have_tunables=no])
AC_SUBST(have_tunables)
@@ -36,8 +36,10 @@ ifeq (yes,$(use-ldconfig))
dl-routines += dl-cache
endif
-ifeq (yes,$(have-tunables))
+ifneq (no,$(have-tunables))
dl-routines += dl-tunables
+tunables-type = $(addprefix TUNABLES_FRONTEND_,$(have-tunables))
+CPPFLAGS-dl-tunables.c = -DTUNABLES_FRONTEND=$(tunables-type)
endif
all-dl-routines = $(dl-routines) $(sysdep-dl-routines)
@@ -30,7 +30,9 @@
#define TUNABLES_INTERNAL 1
#include "dl-tunables.h"
-#define GLIBC_TUNABLES "GLIBC_TUNABLES"
+#if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
+# define GLIBC_TUNABLES "GLIBC_TUNABLES"
+#endif
/* Compare environment or tunable names, bounded by the name hardcoded in
glibc. */
@@ -48,6 +50,7 @@ is_name (const char *orig, const char *envname)
return false;
}
+#if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
static char *
tunables_strdup (const char *in)
{
@@ -69,6 +72,7 @@ tunables_strdup (const char *in)
return out;
}
+#endif
static char **
get_next_env (char **envp, char **name, size_t *namelen, char **val)
@@ -234,6 +238,7 @@ tunable_initialize (tunable_t *cur, const char *strval)
}
}
+#if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
static void
parse_tunables (char *tunestr)
{
@@ -299,6 +304,7 @@ parse_tunables (char *tunestr)
return;
}
}
+#endif
static size_t
min_strlen (const char *s)
@@ -319,6 +325,7 @@ disable_tunable (tunable_id_t id, char **envp)
if (env_alias)
tunables_unsetenv (envp, tunable_list[id].env_alias);
+#if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
char *tunable = getenv (GLIBC_TUNABLES);
const char *cmp = tunable_list[id].name;
const size_t len = min_strlen (cmp);
@@ -335,6 +342,7 @@ disable_tunable (tunable_id_t id, char **envp)
}
tunable++;
}
+#endif
}
/* Disable the glibc.malloc.check tunable in SETUID/SETGID programs unless
@@ -365,6 +373,7 @@ __tunables_init (char **envp)
while ((envp = get_next_env (envp, &envname, &len, &envval)) != NULL)
{
+#if TUNABLES_FRONTEND == TUNABLES_FRONTEND_valstring
if (is_name (GLIBC_TUNABLES, envname))
{
char *val = tunables_strdup (envval);
@@ -372,6 +381,7 @@ __tunables_init (char **envp)
parse_tunables (val);
continue;
}
+#endif
for (int i = 0; i < sizeof (tunable_list) / sizeof (tunable_t); i++)
{
@@ -75,4 +75,8 @@ extern void __tunable_set_val (tunable_id_t, void *, tunable_callback_t);
/* Namespace sanity for callback functions. Use this macro to keep the
namespace of the modules clean. */
#define DL_TUNABLE_CALLBACK(__name) _dl_tunable_ ## __name
+
+# define TUNABLES_FRONTEND_valstring 1
+/* The default value for TUNABLES_FRONTEND. */
+# define TUNABLES_FRONTEND_yes TUNABLES_FRONTEND_valstring
#endif
@@ -192,7 +192,23 @@ Use this option to disable the vector math library.
@item --enable-tunables
Tunables support allows additional library parameters to be customized at
runtime. This is an experimental feature and affects startup time and is thus
-disabled by default.
+disabled by default. This option can take the following values:
+
+@itemize @bullet
+@item @var{no}
+This is the default if the option is not passed to configure. This disables
+tunables.
+
+@item @var{yes}
+This is the default if the option is passed to configure. This enables tunables
+and selects the default frontend (currently @var{valstring}).
+
+@item @var{valstring}
+This enables tunables and selects the @var{valstring} frontend for tunables.
+This frontend allows users to specify tunables as a colon-separated list in a
+single environment variable @var{GLIBC_TUNABLES}.
+
+@end itemize
@item --build=@var{build-system}
@itemx --host=@var{host-system}