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: Put CPU-related tunables into a unique namespace?


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


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