On Wed, 14 Jan 2015 11:01:16 -0800 Zac Medico <zmed...@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
signature.asc
Description: PGP signature
