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. 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...)
