| 1 |
Andrew Savchenko posted on Tue, 20 Jan 2015 23:59:23 +0300 as excerpted: |
| 2 |
|
| 3 |
> On Tue, 20 Jan 2015 12:17:35 -0800 Christopher Head wrote: |
| 4 |
>> On January 20, 2015 12:47:03 AM PST, Alexis Ballier |
| 5 |
>> <aballier@g.o> wrote: |
| 6 |
>> >So, you're telling me that if you have a list of 90 cpu extensions, |
| 7 |
>> >you will from time to time open that list to see if there is a 91st |
| 8 |
>> >one added ? I think most people won't even notice, at best they'll |
| 9 |
>> >look for the changelog. |
| 10 |
>> |
| 11 |
>> No, actually, I’m advocating the exact opposite. I’m saying that, as |
| 12 |
>> long as the list file is kept up to date, then I will look at those 90 |
| 13 |
>> flags when I first install and never again. If a 91st flag appears some |
| 14 |
>> day, then as long as the file was maintained as I described in an |
| 15 |
>> earlier message (i.e. flags are added as soon as manufacturers announce |
| 16 |
>> features), I already know I can reliably ignore the new flag. After |
| 17 |
>> all, |
| 18 |
>> if the flag didn’t exist when I installed the system, then my CPU must |
| 19 |
>> necessarily not have that feature—unless CPUs are in the habit of |
| 20 |
>> sprouting new instructions after you buy them! |
| 21 |
> |
| 22 |
> Not exactly. CPUs are not in a habit, but software is. Some brand new |
| 23 |
> instuction set may be supported in (any of) packages with some delay. |
| 24 |
> Thus it is possible that instruction set supported by your CPU will |
| 25 |
> appear in the list of cpu flags after your ininial install. |
| 26 |
|
| 27 |
PMFJI... |
| 28 |
|
| 29 |
chead's idea is (I believe) simply to have the description file updated |
| 30 |
with all current hardware feature flags as soon as they are known (he |
| 31 |
said announced, but sometimes they change between announcement and |
| 32 |
actually appearing in hardware, so "known", as in "known to actually |
| 33 |
appear in hardware", would seem to be better). |
| 34 |
|
| 35 |
That way, no matter what the software supported at the time and what |
| 36 |
flags were thus actually used in packages, when someone first installs |
| 37 |
gentoo on a new machine, or when they first upgrade their CPU to |
| 38 |
something with new features, they can run the script and update their |
| 39 |
use_expand to match their hardware _ONCE_, without worrying about whether |
| 40 |
or when a package with support for it might appear. |
| 41 |
|
| 42 |
If no package with that support ever appears, no harm done, that entry in |
| 43 |
the use_expand is simply never used. |
| 44 |
|
| 45 |
OTOH when some package /does/ get support for new hardware instructions |
| 46 |
and adds the appropriate flag, it'll appear in portage's output, but |
| 47 |
because the use_expand was already set when gentoo was installed or the |
| 48 |
cpu upgraded, the user won't have to worry about needing to look it up |
| 49 |
and decide whether to set it, again, it'll already be done, back when the |
| 50 |
_hardware_ changed, _not_ sometime later, when the _software_ changed to |
| 51 |
support the new hardware. |
| 52 |
|
| 53 |
Of course if the user upgrades hardware after a package supports a |
| 54 |
feature, they'll have to upgrade their use_expand setting appropriately |
| 55 |
or miss support for the new instructions, but that's always the case. |
| 56 |
Just if handled as chead suggests, it'd be the case ONLY when the |
| 57 |
hardware is updated, instead of every time a package upgrades its own |
| 58 |
support. |
| 59 |
|
| 60 |
Correct, chead? Does that make things clearer, aballier and bircoph? |
| 61 |
|
| 62 |
=:^) |
| 63 |
|
| 64 |
-- |
| 65 |
Duncan - List replies preferred. No HTML msgs. |
| 66 |
"Every nonfree program has a lord, a master -- |
| 67 |
and if you use the program, he is your master." Richard Stallman |
Archives