On Thu, 15 Jan 2015 12:03:27 +0000 (UTC) Martin Vaeth <mar...@mvath.de> wrote:
> Alexis Ballier <aball...@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.
