Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On 01/14/2015 09:55 AM, Christopher Head wrote: On January 14, 2015 7:16:46 AM PST, Alexis Ballier aball...@gentoo.org wrote: however, i disagree with your rationale: asm for specific cpu extensions tend to be written and tested after given cpu is available, thus if you have a brand new cpu, you want to be notified if a package gains support for this new instruction set Do people really want to be notified if a package gains support for a new instruction set? I know I don’t. Don't worry. You'll only be notified in the sense that you can see the new flags highlighted in the emerge --verbose output. I would rather have all possible instruction set extensions available as flags and set whichever ones my CPU has once, at install time. If a package gains support for an extension later, then whenever it upgrades, it will just work, because the relevant flag will already be set in make.conf from back when I installed Gentoo on the box. Yes, that's how it will work. You just set your flags, or the profile does it for you, and you're done. For this to work right requires that a dev add all the extensions to the flag before I buy the CPU. All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet. Why should we have to foresee the future? We can easily add support for new flags in CPU_FLAGS_* variables at any time. -- Thanks, Zac
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On Wed, 14 Jan 2015 12:58:21 +0100 Michał Górny mgo...@gentoo.org wrote: Solution: per-arch USE_EXPANDs for flags, e.g.: CPU_FLAGS_X86=3dnow 3dnowext avx ... CPU_FLAGS_ARM=neon ... # arm* flags? CPU_FLAGS_MIPS=... # mips* flags? Any specific comments? I can handle x86 but I'd appreciate specific arch teams replying about more exotic arches. +1 For arm we will likely need the following flags (from arm and armv7a profiles use.mask): iwmmxt neon armvfp armv5te armv6 armv6t2 Regards, Markus signature.asc Description: PGP signature
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
Am Mittwoch, 14. Januar 2015, 12:58:21 schrieb Michał Górny: Solution: per-arch USE_EXPANDs for flags, e.g.: CPU_FLAGS_X86=3dnow 3dnowext avx ... CPU_FLAGS_ARM=neon ... # arm* flags? CPU_FLAGS_MIPS=... # mips* flags? I like it, because it standardizes and removes causes for confusion. So, +1. That said, long time ago I was taught that instruction set use-flags should be avoided as much as possible. I don't remember the source for that anymore. Question to all, is that documented anywhere, and what are the specifics? I suspect use flags that only switch CFLAGS etc are forbidden, useflags that enable assembler code etc are allowed? -- Andreas K. Huettel Gentoo Linux developer dilfri...@gentoo.org http://www.akhuettel.de/ signature.asc Description: This is a digitally signed message part.
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On 01/14/2015 10:28 AM, Anthony G. Basile wrote: Would this approach clean up some of the masking? Eg. I hate having to mask sse and friends in base/use.mask and then unmask them in arch/amd64/use.mask. I'm not sure if there's a technique to make a use expand flags relevant only for a particular profile. The USE_EXPAND flags are essentially the same a regular USE flags. The special technique for masking USE_EXPAND flags would be to mask flags like cpu_flags_neon as though they are regular USE flags. -- Thanks, Zac
Re: [gentoo-portage-dev] Re: [PATCH] emerge: add --changed-deps/--binpkg-changed-deps (282927)
On Wed, 14 Jan 2015 15:26:49 -0800 Zac Medico zmed...@gentoo.org wrote: On 12/23/2014 12:45 PM, Zac Medico wrote: The @changed-deps set is useful, but it has limitations similar to the @installed set (see bug #387059), which can make it unsuitable for use when updating the whole system. Therefore, implement two new options that are analogous to --newuse and --binpkg-respect-use, called --changed-deps and --binpkg-changed-deps. The rationale for having a separate --binpkg-* option is the same in both cases: depending on the situation, people may want different behavior for binary packages. For example, just like ---binpkg-respect-use is automatically enabled if the user has not specified --usepkgonly, so is --binpkg-changed-deps (though the user can explicitly override the automatic behavior). In both cases, inconsistencies in dependencies are automatically avoided, increasing the probability of a successful dependency calculation. X-Gentoo-Bug: 282927 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282927 --- man/emerge.1| 22 +++- pym/_emerge/create_depgraph_params.py | 16 +++ pym/_emerge/depgraph.py | 138 ++-- pym/_emerge/main.py | 26 + pym/portage/dep/_slot_operator.py | 13 +++ pym/portage/tests/resolver/test_changed_deps.py | 120 + 6 files changed, 323 insertions(+), 12 deletions(-) create mode 100644 pym/portage/tests/resolver/test_changed_deps.py Any feedback on this? I think it's good to merge. yeah, looks good, merge approved :) -- Brian Dolbec dolsen
[gentoo-portage-dev] Re: [PATCH] emerge: add --changed-deps/--binpkg-changed-deps (282927)
On 12/23/2014 12:45 PM, Zac Medico wrote: The @changed-deps set is useful, but it has limitations similar to the @installed set (see bug #387059), which can make it unsuitable for use when updating the whole system. Therefore, implement two new options that are analogous to --newuse and --binpkg-respect-use, called --changed-deps and --binpkg-changed-deps. The rationale for having a separate --binpkg-* option is the same in both cases: depending on the situation, people may want different behavior for binary packages. For example, just like ---binpkg-respect-use is automatically enabled if the user has not specified --usepkgonly, so is --binpkg-changed-deps (though the user can explicitly override the automatic behavior). In both cases, inconsistencies in dependencies are automatically avoided, increasing the probability of a successful dependency calculation. X-Gentoo-Bug: 282927 X-Gentoo-Bug-URL: https://bugs.gentoo.org/show_bug.cgi?id=282927 --- man/emerge.1| 22 +++- pym/_emerge/create_depgraph_params.py | 16 +++ pym/_emerge/depgraph.py | 138 ++-- pym/_emerge/main.py | 26 + pym/portage/dep/_slot_operator.py | 13 +++ pym/portage/tests/resolver/test_changed_deps.py | 120 + 6 files changed, 323 insertions(+), 12 deletions(-) create mode 100644 pym/portage/tests/resolver/test_changed_deps.py Any feedback on this? I think it's good to merge. -- Thanks, Zac
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On Wed, 14 Jan 2015 12:58:21 +0100 Michał Górny mgo...@gentoo.org wrote: Any specific comments? I can handle x86 but I'd appreciate specific arch teams replying about more exotic arches. +1 i like the idea, but with a list of useflags that would get converted this could reach more people i think profiles/base/use.mask should be organized enough to easily get such a list however, i disagree with your rationale: asm for specific cpu extensions tend to be written and tested after given cpu is available, thus if you have a brand new cpu, you want to be notified if a package gains support for this new instruction set the advantages I see is that for packages like mplayer or ffmpeg, it is a pain to distinguish what is a cpu extension, what is a codec or what is just a preference over an external lib; this would make it clear. USE_EXPAND_HIDDEN would also make irrelevant flags for your architecture hidden and not just masked. Alexis.
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On January 14, 2015 7:16:46 AM PST, Alexis Ballier aball...@gentoo.org wrote: however, i disagree with your rationale: asm for specific cpu extensions tend to be written and tested after given cpu is available, thus if you have a brand new cpu, you want to be notified if a package gains support for this new instruction set Do people really want to be notified if a package gains support for a new instruction set? I know I don’t. I would rather have all possible instruction set extensions available as flags and set whichever ones my CPU has once, at install time. If a package gains support for an extension later, then whenever it upgrades, it will just work, because the relevant flag will already be set in make.conf from back when I installed Gentoo on the box. For this to work right requires that a dev add all the extensions to the flag before I buy the CPU. All that requires is knowing the names, though; it would be fine if no package actually uses the feature yet. -- Christopher Head
Re: [gentoo-dev] Moving CPU flags into USE_EXPAND
On 01/14/15 10:16, Alexis Ballier wrote: On Wed, 14 Jan 2015 12:58:21 +0100 Michał Górny mgo...@gentoo.org wrote: Any specific comments? I can handle x86 but I'd appreciate specific arch teams replying about more exotic arches. +1 i like the idea, but with a list of useflags that would get converted this could reach more people i think This sounds good to me too. Expansions to the base instruction set architecture is something more pertinent to the intel family going back to the pentium II days with mmx afaik and multiplying like rabbits every since. There is neon for arm and I don't know of any for mips or ppc. Would this approach clean up some of the masking? Eg. I hate having to mask sse and friends in base/use.mask and then unmask them in arch/amd64/use.mask. I'm not sure if there's a technique to make a use expand flags relevant only for a particular profile. -- Anthony G. Basile, Ph.D. Gentoo Linux Developer [Hardened] E-Mail: bluen...@gentoo.org GnuPG FP : 1FED FAD9 D82C 52A5 3BAB DC79 9384 FA6E F52D 4BBA GnuPG ID : F52D4BBA
[gentoo-dev] Moving CPU flags into USE_EXPAND
Hi, I think this has been discussed already [1] but in the end never was applied or even finished discussing. So I'd like to revive the topic and apply the necessary changes in a few days if nobody objects strongly. Rationale: we have a growing number of CPU-corresponding flags that all are fit as global USE flags by definition and are usually set once by user. As far as I'm aware, CPUs don't grow new instruction sets once installed, so in most of the cases user doesn't need to be concerned by additional cryptic flag names once he set up his CPU. Solution: per-arch USE_EXPANDs for flags, e.g.: CPU_FLAGS_X86=3dnow 3dnowext avx ... CPU_FLAGS_ARM=neon ... # arm* flags? CPU_FLAGS_MIPS=... # mips* flags? Any specific comments? I can handle x86 but I'd appreciate specific arch teams replying about more exotic arches. [1]:http://thread.gmane.org/gmane.linux.gentoo.devel/69141 -- Best regards, Michał Górny pgpvXfbEL7jx4.pgp Description: OpenPGP digital signature
