This is the mail archive of the
libc-alpha@sourceware.org
mailing list for the glibc project.
Re: Put CPU-related tunables into a unique namespace?
- From: Tulio Magno Quites Machado Filho <tuliom at linux dot vnet dot ibm dot com>
- To: "Carlos O'Donell" <carlos at redhat dot com>, Szabolcs Nagy <szabolcs dot nagy at arm dot com>, "H.J. Lu" <hjl dot tools at gmail dot com>, GNU C Library <libc-alpha at sourceware dot org>
- Cc:
- Date: Wed, 11 Jul 2018 17:32:55 -0300
- Subject: Re: Put CPU-related tunables into a unique namespace?
- References: <0b01d5de-29c8-ba7f-06fb-8048458df0e3@redhat.com>
Carlos O'Donell <carlos@redhat.com> writes:
> Should we use an arch namespace for CPU-related tunables?
>
> e.g.
>
> glibc.tune.x86.*
> glibc.tune.aarch64.*
> glibc.tune.power.*
>
> We currently have:
>
> glibc.tune.
> .hwcaps
> .cached_memopt
> .cpu
>
> Which all look like they are "generic", but .hwcaps is
> x86 only, .cached_memopt is ppc only, and .cpu is aarch64
> only.
I have no strong opinion on this, but I do have some questions:
Do you plan to rename them now?
What would be the rules to get a tunable in/out a namespace? In other words,
what happens if a new tunable is supported by 2 machines? e.g.
glibc.elision.enable (I understand it's in another namespace, but it's the best
example I have :-) ).
--
Tulio Magno