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 > >> <aball...@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
pgp3WmXtTRs_U.pgp
Description: PGP signature
