[gentoo-dev] Moving CPU flags into USE_EXPAND

[gentoo-dev] Moving CPU flags into USE_EXPAND

[Michał Górny]

[-- Attachment #1: Type: text/plain, Size: 961 bytes --]

Hi,

I think this has been discussed already [1] but in the end never was
applied or even finished discussing. So I'd like to revive the topic
and apply the necessary changes in a few days if nobody objects
strongly.

Rationale: we have a growing number of CPU-corresponding flags that all
are fit as global USE flags by definition and are usually set once
by user. As far as I'm aware, CPUs don't grow new instruction sets once
installed, so in most of the cases user doesn't need to be concerned by
additional cryptic flag names once he set up his CPU.

Solution: per-arch USE_EXPANDs for flags, e.g.:

  CPU_FLAGS_X86="3dnow 3dnowext avx ..."
  CPU_FLAGS_ARM="neon ..." # arm* flags?
  CPU_FLAGS_MIPS="..." # mips* flags?

Any specific comments? I can handle x86 but I'd appreciate specific
arch teams replying about more exotic arches.

[1]:http://thread.gmane.org/gmane.linux.gentoo.devel/69141

-- 
Best regards,
Michał Górny

[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 949 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Any specific comments? I can handle x86 but I'd appreciate specific
> arch teams replying about more exotic arches.

+1

i like the idea, but with a list of useflags that would get converted
this could "reach" more people i think

profiles/base/use.mask should be organized enough to easily get such a
list

however, i disagree with your rationale: asm for specific cpu
extensions tend to be written and tested after given cpu is available,
thus if you have a brand new cpu, you want to be notified if a package
gains support for this new instruction set

the advantages I see is that for packages like mplayer or ffmpeg, it
is a pain to distinguish what is a cpu extension, what is a codec or
what is just a preference over an external lib; this would make it
clear.

USE_EXPAND_HIDDEN would also make irrelevant flags for your
architecture hidden and not just masked.


Alexis.

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Christopher Head]

On January 14, 2015 7:16:46 AM PST, Alexis Ballier <aballier@gentoo.org> wrote:
>however, i disagree with your rationale: asm for specific cpu
>extensions tend to be written and tested after given cpu is available,
>thus if you have a brand new cpu, you want to be notified if a package
>gains support for this new instruction set

Do people really want to be notified if a package gains support for a new instruction set? I know I don’t. I would rather have all possible instruction set extensions available as flags and set whichever ones my CPU has once, at install time. If a package gains support for an extension later, then whenever it upgrades, it will just work, because the relevant flag will already be set in make.conf from back when I installed Gentoo on the box.

For this to work right requires that a dev add all the extensions to the flag before I buy the CPU. All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet.

-- 
Christopher Head

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Anthony G. Basile]

On 01/14/15 10:16, Alexis Ballier wrote:
> On Wed, 14 Jan 2015 12:58:21 +0100
> Michał Górny <mgorny@gentoo.org> wrote:
>
>> Any specific comments? I can handle x86 but I'd appreciate specific
>> arch teams replying about more exotic arches.
> +1
>
> i like the idea, but with a list of useflags that would get converted
> this could "reach" more people i think

This sounds good to me too.  Expansions to the base instruction set 
architecture is something more pertinent to the intel family going back 
to the pentium II days with mmx afaik and multiplying like rabbits every 
since.  There is neon for arm and I don't know of any for mips or ppc.

Would this approach clean up some of the masking?  Eg. I hate having to 
mask sse and friends in base/use.mask and then unmask them in 
arch/amd64/use.mask.  I'm not sure if there's a technique to make a use 
expand flags relevant only for a particular profile.

-- 
Anthony G. Basile, Ph.D.
Gentoo Linux Developer [Hardened]
E-Mail    : blueness@gentoo.org
GnuPG FP  : 1FED FAD9 D82C 52A5 3BAB  DC79 9384 FA6E F52D 4BBA
GnuPG ID  : F52D4BBA

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Zac Medico]

On 01/14/2015 10:28 AM, Anthony G. Basile wrote:
> Would this approach clean up some of the masking?  Eg. I hate having to
> mask sse and friends in base/use.mask and then unmask them in
> arch/amd64/use.mask.  I'm not sure if there's a technique to make a use
> expand flags relevant only for a particular profile.

The USE_EXPAND flags are essentially the same a regular USE flags. The
"special technique" for masking USE_EXPAND flags would be to mask flags
like cpu_flags_neon as though they are regular USE flags.
-- 
Thanks,
Zac

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Zac Medico]

On 01/14/2015 09:55 AM, Christopher Head wrote:
> On January 14, 2015 7:16:46 AM PST, Alexis Ballier <aballier@gentoo.org> wrote:
>> however, i disagree with your rationale: asm for specific cpu
>> extensions tend to be written and tested after given cpu is available,
>> thus if you have a brand new cpu, you want to be notified if a package
>> gains support for this new instruction set
> 
> Do people really want to be notified if a package gains support for a new instruction set? I know I don’t. 

Don't worry. You'll only be "notified" in the sense that you can see the
new flags highlighted in the emerge --verbose output.

> I would rather have all possible instruction set extensions available as flags and set whichever ones my CPU has once, at install time. If a package gains support for an extension later, then whenever it upgrades, it will just work, because the relevant flag will already be set in make.conf from back when I installed Gentoo on the box.

Yes, that's how it will work. You just set your flags, or the profile
does it for you, and you're done.

> For this to work right requires that a dev add all the extensions to the flag before I buy the CPU. All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet.

Why should we have to foresee the future? We can easily add support for
new flags in CPU_FLAGS_* variables at any time.
-- 
Thanks,
Zac

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Andreas K. Huettel]

[-- Attachment #1: Type: Text/Plain, Size: 802 bytes --]

Am Mittwoch, 14. Januar 2015, 12:58:21 schrieb Michał Górny:
> 
> Solution: per-arch USE_EXPANDs for flags, e.g.:
> 
>   CPU_FLAGS_X86="3dnow 3dnowext avx ..."
>   CPU_FLAGS_ARM="neon ..." # arm* flags?
>   CPU_FLAGS_MIPS="..." # mips* flags?
> 

I like it, because it standardizes and removes causes for confusion. So, +1.

That said, long time ago I was taught that "instruction set use-flags" should 
be avoided as much as possible. I don't remember the source for that anymore. 

Question to all, is that documented anywhere, and what are the specifics?
I suspect "use flags that only switch CFLAGS etc" are forbidden, "useflags 
that enable assembler code etc" are allowed?

-- 

Andreas K. Huettel
Gentoo Linux developer 
dilfridge@gentoo.org
http://www.akhuettel.de/


[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 951 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Markus Meier]

[-- Attachment #1: Type: text/plain, Size: 557 bytes --]

On Wed, 14 Jan 2015 12:58:21 +0100
Michał Górny <mgorny@gentoo.org> wrote:

> Solution: per-arch USE_EXPANDs for flags, e.g.:
> 
>   CPU_FLAGS_X86="3dnow 3dnowext avx ..."
>   CPU_FLAGS_ARM="neon ..." # arm* flags?
>   CPU_FLAGS_MIPS="..." # mips* flags?
> 
> Any specific comments? I can handle x86 but I'd appreciate specific
> arch teams replying about more exotic arches.

+1

For arm we will likely need the following flags (from arm and armv7a
profiles use.mask):
iwmmxt
neon
armvfp
armv5te
armv6
armv6t2


Regards,
Markus

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 181 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Wed, 14 Jan 2015 21:59:37 +0100
"Andreas K. Huettel" <dilfridge@gentoo.org> wrote:

> That said, long time ago I was taught that "instruction set
> use-flags" should be avoided as much as possible. I don't remember
> the source for that anymore. 
> 
> Question to all, is that documented anywhere, and what are the
> specifics? I suspect "use flags that only switch CFLAGS etc" are
> forbidden, "useflags that enable assembler code etc" are allowed?
> 

I don't think this is documented besides the fact that forcing cflags
is forbidden.

For asm code you don't have much choice: either your package compiles
all asm and has some kind of cpu detection so that it choses the best
implementation at runtime (wasting a bit of resources), either if you
enable something your cpu doesn't support then your program gets killed
by SIGILL.
Also, this is not the case for x86* but iirc on arm, if your cflags
have some -march or -mcpu then gcc forwards it to as which in turns
refuses any instruction not supported by your cpu: you must disable
forbidden instructions in order to build your package.

Alexis.

[gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Martin Vaeth]

Christopher Head <chead@chead.ca> wrote:
>
> All that requires is knowing the names, though; it would be
> fine if no package actually uses the feature yet.

++

More precisely: When changing the names anyway,
IMHO it would be a very good idea to follow the convention of the
"flag" names in /proc/cpuinfo and add all flags supported
there as possible USE-flags, no matter, whether they are currently
used in some package or not.
The list might still be extended when a new processor with new features
comes out.

If this is done properly, the user could easily write a script to set
these flags appropriate for his current machine. One might even give
portage a "--use-native" switch (or FEATURE=use-native)
which sets the USE defaults corresponding to the current
/proc/cpuinfo output. The latter is what typical desktop users
probably would prefer: A complete analogue of CFLAGS=-march=native;
just generating optimal code for his machine, without requiring
the user to understand all the fancy details of his processor.

To properly support packages which can choose the appropriate code
at runtime, I suggest to add in addition an "all" flag which just
compiles in all possible optimized code-paths.

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Thu, 15 Jan 2015 10:20:15 +0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:

> Christopher Head <chead@chead.ca> wrote:
> >
> > All that requires is knowing the names, though; it would be
> > fine if no package actually uses the feature yet.
> 
> ++
> 
> More precisely: When changing the names anyway,
> IMHO it would be a very good idea to follow the convention of the
> "flag" names in /proc/cpuinfo and add all flags supported
> there as possible USE-flags, no matter, whether they are currently
> used in some package or not.


seriously ?

$ grep flags /proc/cpuinfo | head -n 1 | wc -w
94

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[vivo75]

Il 15/01/2015 11:30, Alexis Ballier ha scritto:
> On Thu, 15 Jan 2015 10:20:15 +0000 (UTC)
> Martin Vaeth <martin@mvath.de> wrote:
>
>> Christopher Head <chead@chead.ca> wrote:
>>> All that requires is knowing the names, though; it would be
>>> fine if no package actually uses the feature yet.
>> ++
>>
>> More precisely: When changing the names anyway,
>> IMHO it would be a very good idea to follow the convention of the
>> "flag" names in /proc/cpuinfo and add all flags supported
>> there as possible USE-flags, no matter, whether they are currently
>> used in some package or not.
>
> seriously ?
>
> $ grep flags /proc/cpuinfo | head -n 1 | wc -w
> 94
>

Actually I like the idea, there are performances problems  related to
ebuilds or portage?

CPU_FLAGS=$(grep -m1 flags /proc/cpuinfo)
CPU_FLAGS=${CPU_FLAGS#*:}
echo $CPU_FLAGS | wc -w
92

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Thu, 15 Jan 2015 11:50:25 +0100
"vivo75@gmail.com" <vivo75@gmail.com> wrote:

> Il 15/01/2015 11:30, Alexis Ballier ha scritto:
> > On Thu, 15 Jan 2015 10:20:15 +0000 (UTC)
> > Martin Vaeth <martin@mvath.de> wrote:
> >
> >> Christopher Head <chead@chead.ca> wrote:
> >>> All that requires is knowing the names, though; it would be
> >>> fine if no package actually uses the feature yet.
> >> ++
> >>
> >> More precisely: When changing the names anyway,
> >> IMHO it would be a very good idea to follow the convention of the
> >> "flag" names in /proc/cpuinfo and add all flags supported
> >> there as possible USE-flags, no matter, whether they are currently
> >> used in some package or not.
> >
> > seriously ?
> >
> > $ grep flags /proc/cpuinfo | head -n 1 | wc -w
> > 94
> >
> 
> Actually I like the idea, there are performances problems  related to
> ebuilds or portage?


it is not about performance but rather about writing the proper .desc
file; i don't think this will ever happen if nobody baking up the idea
comes with such a file

Alexis.

[gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Martin Vaeth]

Alexis Ballier <aballier@gentoo.org> wrote:
>> >>
>> >> More precisely: When changing the names anyway,
>> >> IMHO it would be a very good idea to follow the convention of the
>> >> "flag" names in /proc/cpuinfo and add all flags supported
>> >> there as possible USE-flags, no matter, whether they are currently
>> >> used in some package or not.
>> >
>> > seriously ?
>> >
>> > $ grep flags /proc/cpuinfo | head -n 1 | wc -w
>> > 94

Well, currently, we have at least 10-20 already:
At a very quick check (probably missing some), I found:

mmx sse sse2 aes-ni ssse3 sse3 sse4 sse4a sse4.1 sse4.2
3des 3dnow 3dnowext

and probably there are more to be added anyway
in future packages.

I am not even sure whether some of these sse4* are dupes
or not since they do not follow /proc/cpuinfo convention.
Some others do not follow this convention at all,
e.g. "sse3" is called "pni" in /proc/cpuinfo
or "aes-ni" is called "aes" in /proc/cpuinfo

This is mainly what I meant: Currently, users have to look
up how sse3 is called in /proc/cpuinfo to understand whether
their processor has support for it. This could be automated.

If not all of the 94 flags are included, it is perhaps not a drama;
my main suggestion is to follow /proc/cpuinfo convention in the
existing ones.

> but rather about writing the proper .desc file

Well, currently the descriptions are:

3dnow: Use the 3DNow! instruction set
mmx: Use the mmx instruction set
sse: Use the SSE2 instruction set
sse4_1: Enable sse4.1 acceleration
...

So they are practically useless unless you know anyway what the
corresponding processor flags mean.
I suggest to start with a "stub" .desc list, e.g.:

yyy: Use the yyy CPU feature, cf. /proc/cpuinfo

This is enough for the user to check on which of his systems he
might want it.  A more verbose description can be added for some
flags some day as a bonus; such a list can grow over time, and some
experts might want to send some patches to fix/extend the descriptions.
But why require for the start more than we have currently?
If there is no list to start with, then you can also not expect
that somebody will suggest patches (I mean: to a non-listed feature...)

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Thu, 15 Jan 2015 12:03:27 +0000 (UTC)
Martin Vaeth <martin@mvath.de> wrote:

> Alexis Ballier <aballier@gentoo.org> wrote:
> >> >>
> >> >> More precisely: When changing the names anyway,
> >> >> IMHO it would be a very good idea to follow the convention of
> >> >> the "flag" names in /proc/cpuinfo and add all flags supported
> >> >> there as possible USE-flags, no matter, whether they are
> >> >> currently used in some package or not.
> >> >
> >> > seriously ?
> >> >
> >> > $ grep flags /proc/cpuinfo | head -n 1 | wc -w
> >> > 94
> 
> Well, currently, we have at least 10-20 already:
> At a very quick check (probably missing some), I found:
> 
> mmx sse sse2 aes-ni ssse3 sse3 sse4 sse4a sse4.1 sse4.2
> 3des 3dnow 3dnowext
> 
> and probably there are more to be added anyway
> in future packages.
> 
> I am not even sure whether some of these sse4* are dupes
> or not since they do not follow /proc/cpuinfo convention.
> Some others do not follow this convention at all,
> e.g. "sse3" is called "pni" in /proc/cpuinfo
> or "aes-ni" is called "aes" in /proc/cpuinfo
> 
> This is mainly what I meant: Currently, users have to look
> up how sse3 is called in /proc/cpuinfo to understand whether
> their processor has support for it. This could be automated.

/proc/cpuinfo is quite useless as a description

when i added such flags i tried to follow wikipedia naming and added
min cpu version that supported it in the description.
flags are usually extensively described in:
http://en.wikipedia.org/wiki/${uppercase flag}

algo, e.g. pni and aes pages are disambiguation ones, while SSE3 and
AES-NI are quite clear on what they are.

from wikipedia:
- SSE2, Willamette New Instructions (WNI)
- SSE3, also called Prescott New Instructions (PNI)
- SSSE3, Merom New Instructions (MNI)
- SSE4, Penryn New Instructions (PNI)
- AVX (Advanced Vector Extensions), Gesher New Instructions (GNI)


why do I have pni and avx in /proc/cpuinfo ?
this sounds quite inconsistent and is probably due to the fact that
those flags are added early in the kernel and have to stay forever,
while the naming might end up being a poor naming a few months or
years later. sys-apps/cpuid disambiguates it better.


I don't think it is a good idea to forward this inconsistency as-is:
better write a cpuinfo2useflags script that you could >> to make.conf
if automation is really the goal.

Alexis.

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Christopher Head]

[-- Attachment #1: Type: text/plain, Size: 1969 bytes --]

On Wed, 14 Jan 2015 11:01:16 -0800
Zac Medico <zmedico@gentoo.org> wrote:

> Why should we have to foresee the future? We can easily add support
> for new flags in CPU_FLAGS_* variables at any time.

Ah, what I meant was that whoever maintains this flag list only needs
to forsee the present—when AMD or Intel adds a new instruction set
extension, you add a flag for it to the variable immediately, whether
or not any package actually uses it yet. Why? Here’s why:

Case 1: flags are added only as packages need them. This is pretty much
what we have today, only without the USE-expand feature. Every time a
package adds support for a new CPU feature, it gets a new USE flag, and
I see it in my emerge output. Now I have to go and look up what the
feature is, what it would be called in cpuinfo, and whether I have it.
Maybe I already looked up the same CPU feature two or three times, many
months ago, and forgot about it, for some other package. Lots of wasted
work. But I can’t just ignore it, because maybe this is the first time
that flag showed up, because no package ever used that feature before,
but my CPU *does* have it, so I really want to turn it on!

Case 2: flags are all added immediately as the CPU features are
announced. When I install Gentoo, all the possible flags for my CPU are
already listed in the variable. I immediately turn all those I have on
and all those I don’t have off. Done. Now I can completely stop paying
attention to the flags. As packages gain support, they gain new flags,
and I can ignore them, secure in the knowledge that the flags for those
features I have will all be turned on, while those I don’t have will be
turned off, with no further input from me. Nice and easy.

I’m not saying add flags for feature sets that haven’t been announced
yet. I’m just saying, add flags for feature sets that *are* announced
but that no package actually uses yet.
-- 
Christopher Head

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Mon, 19 Jan 2015 23:43:19 -0800
Christopher Head <chead@chead.ca> wrote:

> On Wed, 14 Jan 2015 11:01:16 -0800
> Zac Medico <zmedico@gentoo.org> wrote:
> 
> > Why should we have to foresee the future? We can easily add support
> > for new flags in CPU_FLAGS_* variables at any time.
> 
> Ah, what I meant was that whoever maintains this flag list only needs
> to forsee the present—when AMD or Intel adds a new instruction set
> extension, you add a flag for it to the variable immediately, whether
> or not any package actually uses it yet. Why? Here’s why:
> 
> Case 1: flags are added only as packages need them. This is pretty
> much what we have today, only without the USE-expand feature. Every
> time a package adds support for a new CPU feature, it gets a new USE
> flag, and I see it in my emerge output.
[...]

you will not see it if no package use it.


Alexis.

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Christopher Head]

[-- Attachment #1: Type: text/plain, Size: 587 bytes --]

On Tue, 20 Jan 2015 09:21:54 +0100
Alexis Ballier <aballier@gentoo.org> wrote:

> you will not see it if no package use it.

I guess you mean I wouldn’t see it in emerge output if no package uses
it, even if it is USE-expanded? Yes, I’m aware of that. But if all the
flags are listed together in one place (I forget what the file was
called—cpu.flags.use.desc or something?), then I can just open that
file to see the list, hence why case 2 is better IMO—put all the
entries in that file for users to look at, even if no package uses them
yet.
-- 
Christopher Head

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Alexis Ballier]

On Tue, 20 Jan 2015 00:29:22 -0800
Christopher Head <chead@chead.ca> wrote:

> On Tue, 20 Jan 2015 09:21:54 +0100
> Alexis Ballier <aballier@gentoo.org> wrote:
> 
> > you will not see it if no package use it.
> 
> I guess you mean I wouldn’t see it in emerge output if no package uses
> it, even if it is USE-expanded? Yes, I’m aware of that. But if all the
> flags are listed together in one place (I forget what the file was
> called—cpu.flags.use.desc or something?), then I can just open that
> file to see the list, hence why case 2 is better IMO—put all the
> entries in that file for users to look at, even if no package uses
> them yet.

So, you're telling me that if you have a list of 90 cpu extensions, you
will from time to time open that list to see if there is a 91st one
added ? I think most people won't even notice, at best they'll look for
the changelog.

Isn't it better to have a script, e.g. in gentoo-x86/scripts (that
would be the first of this kind here I think), that would
"parse" /proc/cpuinfo and output 'CPU_FLAGS_...="..."' so that for a
first install you can simply send its output to make.conf and, if you
are paranoid, can use it to check if this has changed in a postsync
hook ?

Alexis.

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Christopher Head]

On January 20, 2015 12:47:03 AM PST, Alexis Ballier <aballier@gentoo.org> wrote:
>So, you're telling me that if you have a list of 90 cpu extensions, you
>will from time to time open that list to see if there is a 91st one
>added ? I think most people won't even notice, at best they'll look for
>the changelog.

No, actually, I’m advocating the exact opposite. I’m saying that, as long as the list file is kept up to date, then I will look at those 90 flags when I first install and never again. If a 91st flag appears some day, then as long as the file was maintained as I described in an earlier message (i.e. flags are added as soon as manufacturers announce features), I already know I can reliably ignore the new flag. After all, if the flag didn’t exist when I installed the system, then my CPU must necessarily not have that feature—unless CPUs are in the habit of sprouting new instructions after you buy them!

>Isn't it better to have a script, e.g. in gentoo-x86/scripts (that
>would be the first of this kind here I think), that would
>"parse" /proc/cpuinfo and output 'CPU_FLAGS_...="..."' so that for a
>first install you can simply send its output to make.conf and, if you
>are paranoid, can use it to check if this has changed in a postsync
>hook ?

I see having a script to select flag values as orthogonal to when the flag values need to be looked at. I also agree that having a script would be a good thing.

-- 
Christopher Head

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 1318 bytes --]

On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
> On January 20, 2015 12:47:03 AM PST, Alexis Ballier <aballier@gentoo.org> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most people won't even notice, at best they'll look for
> >the changelog.
> 
> No, actually, I’m advocating the exact opposite. I’m saying that, as long as the list file is kept up to date, then I will look at those 90 flags when I first install and never again. If a 91st flag appears some day, then as long as the file was maintained as I described in an earlier message (i.e. flags are added as soon as manufacturers announce features), I already know I can reliably ignore the new flag. After all, if the flag didn’t exist when I installed the system, then my CPU must necessarily not have that feature—unless CPUs are in the habit of sprouting new instructions after you buy them!

Not exactly. CPUs are not in a habit, but software is. Some brand
new instuction set may be supported in (any of) packages with some
delay. Thus it is possible that instruction set supported by your
CPU will appear in the list of cpu flags after your ininial install.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]

Re: [gentoo-dev] Moving CPU flags into USE_EXPAND

[Gordon Pettey]

[-- Attachment #1: Type: text/plain, Size: 922 bytes --]

On Tue, Jan 20, 2015 at 2:17 PM, Christopher Head <chead@chead.ca> wrote:

> On January 20, 2015 12:47:03 AM PST, Alexis Ballier <aballier@gentoo.org>
> wrote:
> >So, you're telling me that if you have a list of 90 cpu extensions, you
> >will from time to time open that list to see if there is a 91st one
> >added ? I think most people won't even notice, at best they'll look for
> >the changelog.
>
> No, actually, I’m advocating the exact opposite. I’m saying that, as long
> as the list file is kept up to date, then I will look at those 90 flags


Why do you keep insisting on 90 flags? Nothing is going to have alternate
code paths for whether you've got pse, pse36, pat, fpu, or ept. The vast
majority of the flags in cpuinfo aren't ever going to be in anything
userspace. The kernel might care about them, but even then, most of them
aren't going to be related to any options you can change.

[-- Attachment #2: Type: text/html, Size: 1327 bytes --]

[gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Duncan]

Andrew Savchenko posted on Tue, 20 Jan 2015 23:59:23 +0300 as excerpted:

> On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
>> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
>> <aballier@gentoo.org> wrote:
>> >So, you're telling me that if you have a list of 90 cpu extensions,
>> >you will from time to time open that list to see if there is a 91st
>> >one added ? I think most people won't even notice, at best they'll
>> >look for the changelog.
>> 
>> No, actually, I’m advocating the exact opposite. I’m saying that, as
>> long as the list file is kept up to date, then I will look at those 90
>> flags when I first install and never again. If a 91st flag appears some
>> day, then as long as the file was maintained as I described in an
>> earlier message (i.e. flags are added as soon as manufacturers announce
>> features), I already know I can reliably ignore the new flag. After
>> all,
>> if the flag didn’t exist when I installed the system, then my CPU must
>> necessarily not have that feature—unless CPUs are in the habit of
>> sprouting new instructions after you buy them!
> 
> Not exactly. CPUs are not in a habit, but software is. Some brand new
> instuction set may be supported in (any of) packages with some delay.
> Thus it is possible that instruction set supported by your CPU will
> appear in the list of cpu flags after your ininial install.

PMFJI...

chead's idea is (I believe) simply to have the description file updated 
with all current hardware feature flags as soon as they are known (he 
said announced, but sometimes they change between announcement and 
actually appearing in hardware, so "known", as in "known to actually 
appear in hardware", would seem to be better).

That way, no matter what the software supported at the time and what 
flags were thus actually used in packages, when someone first installs 
gentoo on a new machine, or when they first upgrade their CPU to 
something with new features, they can run the script and update their 
use_expand to match their hardware _ONCE_, without worrying about whether 
or when a package with support for it might appear.

If no package with that support ever appears, no harm done, that entry in 
the use_expand is simply never used.

OTOH when some package /does/ get support for new hardware instructions 
and adds the appropriate flag, it'll appear in portage's output, but 
because the use_expand was already set when gentoo was installed or the 
cpu upgraded, the user won't have to worry about needing to look it up 
and decide whether to set it, again, it'll already be done, back when the 
_hardware_ changed, _not_ sometime later, when the _software_ changed to 
support the new hardware.

Of course if the user upgrades hardware after a package supports a 
feature, they'll have to upgrade their use_expand setting appropriately 
or miss support for the new instructions, but that's always the case.  
Just if handled as chead suggests, it'd be the case ONLY when the 
hardware is updated, instead of every time a package upgrades its own 
support.

Correct, chead?  Does that make things clearer, aballier and bircoph?

=:^)

-- 
Duncan - List replies preferred.   No HTML msgs.
"Every nonfree program has a lord, a master --
and if you use the program, he is your master."  Richard Stallman

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Christopher Head]

[-- Attachment #1: Type: text/plain, Size: 173 bytes --]

On Wed, 21 Jan 2015 01:13:08 +0000 (UTC)
Duncan <1i5t5.duncan@cox.net> wrote:

(a lot)

Thank you, Duncan. You explained by position perfectly.
-- 
Christopher Head

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 648 bytes --]

Re: [gentoo-dev] Re: Moving CPU flags into USE_EXPAND

[Andrew Savchenko]

[-- Attachment #1: Type: text/plain, Size: 3494 bytes --]

On Wed, 21 Jan 2015 01:13:08 +0000 (UTC) Duncan wrote:
> Andrew Savchenko posted on Tue, 20 Jan 2015 23:59:23 +0300 as excerpted:
> 
> > On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote:
> >> On January 20, 2015 12:47:03 AM PST, Alexis Ballier
> >> <aballier@gentoo.org> wrote:
> >> >So, you're telling me that if you have a list of 90 cpu extensions,
> >> >you will from time to time open that list to see if there is a 91st
> >> >one added ? I think most people won't even notice, at best they'll
> >> >look for the changelog.
> >> 
> >> No, actually, I’m advocating the exact opposite. I’m saying that, as
> >> long as the list file is kept up to date, then I will look at those 90
> >> flags when I first install and never again. If a 91st flag appears some
> >> day, then as long as the file was maintained as I described in an
> >> earlier message (i.e. flags are added as soon as manufacturers announce
> >> features), I already know I can reliably ignore the new flag. After
> >> all,
> >> if the flag didn’t exist when I installed the system, then my CPU must
> >> necessarily not have that feature—unless CPUs are in the habit of
> >> sprouting new instructions after you buy them!
> > 
> > Not exactly. CPUs are not in a habit, but software is. Some brand new
> > instuction set may be supported in (any of) packages with some delay.
> > Thus it is possible that instruction set supported by your CPU will
> > appear in the list of cpu flags after your ininial install.
> 
> PMFJI...
> 
> chead's idea is (I believe) simply to have the description file updated 
> with all current hardware feature flags as soon as they are known (he 
> said announced, but sometimes they change between announcement and 
> actually appearing in hardware, so "known", as in "known to actually 
> appear in hardware", would seem to be better).
> 
> That way, no matter what the software supported at the time and what 
> flags were thus actually used in packages, when someone first installs 
> gentoo on a new machine, or when they first upgrade their CPU to 
> something with new features, they can run the script and update their 
> use_expand to match their hardware _ONCE_, without worrying about whether 
> or when a package with support for it might appear.
> 
> If no package with that support ever appears, no harm done, that entry in 
> the use_expand is simply never used.
> 
> OTOH when some package /does/ get support for new hardware instructions 
> and adds the appropriate flag, it'll appear in portage's output, but 
> because the use_expand was already set when gentoo was installed or the 
> cpu upgraded, the user won't have to worry about needing to look it up 
> and decide whether to set it, again, it'll already be done, back when the 
> _hardware_ changed, _not_ sometime later, when the _software_ changed to 
> support the new hardware.
> 
> Of course if the user upgrades hardware after a package supports a 
> feature, they'll have to upgrade their use_expand setting appropriately 
> or miss support for the new instructions, but that's always the case.  
> Just if handled as chead suggests, it'd be the case ONLY when the 
> hardware is updated, instead of every time a package upgrades its own 
> support.
> 
> Correct, chead?  Does that make things clearer, aballier and bircoph?

Yeah, thanks. I misunderstood original intention. It's all clear
now.

Best regards,
Andrew Savchenko

[-- Attachment #2: Type: application/pgp-signature, Size: 819 bytes --]