This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: [PATCH 3/4] Enhance --enable-tunables to select tunables frontend at build time
- From: Siddhesh Poyarekar <siddhesh at sourceware dot org>
- To: Florian Weimer <fweimer at redhat dot com>, libc-alpha at sourceware dot org
- Cc: carlos at redhat dot com, adhemerval dot zanella at linaro dot org
- Date: Wed, 28 Dec 2016 02:40:22 +0530
- Subject: Re: [PATCH 3/4] Enhance --enable-tunables to select tunables frontend at build time
- Authentication-results: sourceware.org; auth=none
- References: <1479285306-11684-1-git-send-email-siddhesh@sourceware.org> <1479285306-11684-4-git-send-email-siddhesh@sourceware.org> <3fdb76d9-8834-a6cc-7da8-d87d428255fb@redhat.com>
- Reply-to: siddhesh at sourceware dot org
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