Put CPU-related tunables into a unique namespace?

[Carlos O'Donell]

On 07/12/2018 09:26 AM, Ramana Radhakrishnan wrote:
> On Thu, Jul 12, 2018 at 2:10 PM, Carlos O'Donell <carlos@redhat.com> wrote:
>> For example the ".tune." namespace is somewhat useless, we *know* they
>> are tunables, why not just use 'glibc.x86.hwcaps'?
> 
>  I would prefer glibc.<archname>.<tunable> than have the additional tune there
> as it doesn't seem to add anything at the top level.

Sounds good to me.

>> So as a starting thought:
>>
>> * If a set of flags apply to 2 or more machines, we could move them into
>>   an arch-independent tunable namespace.
> 
> And are largely semantically equivalent ? This feels to me no 
> different to whether we put command line options in the -f space or
> the -m space in gcc to use a gcc analogy.

I *love* to hear solutions we are already deploying in other projects,
particularly for this kind of UI with users problem.

Yes, they need to be semantically equivalent, otherwise it's the same
name for two different things, which I'd like to avoid.

>> * Within an arch-independent namespace we might have another deeper list
>>   of arch namespaces e.g. glibc.elision.x86.* for x86 specific elision
>>   parameters that would otherwise have gone in glibc.elision.* if they
>>   were generic.
> 
> Using your example above, having glibc.elision.x86 and 
> glibc.x86.elision_params also seems a recipe for mistyping things
> and confusion on the keyboard. Would it be simpler to just say
> glibc.elision.* is all common stuff and glibc.<arch>.elision.* and
> have a correlation that the suboption in the <arch> namespace is the
> same as the top level common name ?

I'd restructure your example into:

glibc.elision.*
glibc.elision.x86.params

So we have really two modes here:

(a) Arches are nested with related content.

glibc.<arch>.* (no applicable namespace)
glibc.<namespace>.*
glibc.<namespace>.<arch>.*

vs.

(b) Arches contain arch-specific content mirroring layout.

glibc.<arch>.* (no applicable namespace)
glibc.<arch>.<namespace>.*
glibc.<namespace>.*

My preference is still for (a).

It simplifies option promotion by deleting the last namespace:

glibc.<namespace>.<arch>.foo => glibc.<namespace>.foo

Preferences?

-- 
Cheers,
Carlos.