Re: [gentoo-dev] splitting out arm keywords
On Wednesday 09 July 2014 03:48:40 Matthew Thode wrote: arm has a historical problem with stabilization, while keywording doesn't require access to all arm sub-arches the problem with the stabilization slowness causes running a full ~arm to become hard. By that I mean that if someone keywords something for arm because it works on armv7 and I run ~arm because stabilization takes forever then my system may break because of both non-stabilized packages and because I could be running armv6. So how common is it for a package to work correctly on armv7 but break on armv6? As far as I can see, splitting the keywords is a good idea if and only if this is common. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. Do you foresee ~armv4 and ~armv5 keywords actually showing up in practice? I think this would be beneficial because of not all developers that want to help with arm have or what all the sub-arches necessary. It also allows us to move faster on stabilization because most of us have access to armv7 a bit easier. This would take some pressure off of the people doing stabilization for older sub-arches, but not much. Some issues that need solving are as follows. [hard|soft]float differences. what stabilization means would need to be clarified a bit here. The same issue as above applies. Do packages commonly break or unbreak depending on hardfloat versus softfloat? -- Ruud
Re: [gentoo-dev] splitting out arm keywords
On 07/08/2014 21:48, Matthew Thode wrote: arm has a historical problem with stabilization, while keywording doesn't require access to all arm sub-arches the problem with the stabilization slowness causes running a full ~arm to become hard. By that I mean that if someone keywords something for arm because it works on armv7 and I run ~arm because stabilization takes forever then my system may break because of both non-stabilized packages and because I could be running armv6. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. Couldn't this be better handled with some profile work? These sound like versions of Instruction Set Architectures. In the MIPS world, you have your original ISAs, mips1 through mips4, then you have the newer variants of mips32r* (branches from mips2) and mips64r* (branches from mips4). Anything supporting mips4 could also support earlier ISAs. Throw in our three supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI, Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can cover all of this with just a single 'mips' keyword in the tree. Is that similar to how these ARM variants work? Can an armv7 run code for armv6 and earlier? Splitting 'arm' into four new keywords, on top of 'arm64' is just going to give you guys major headaches later. You might even consider dedicated USE flags for the arm subvariants and use those to control things in an ebuild where applicable. I think this would be beneficial because of not all developers that want to help with arm have or what all the sub-arches necessary. It also allows us to move faster on stabilization because most of us have access to armv7 a bit easier. This would take some pressure off of the people doing stabilization for older sub-arches, but not much. What's the support status of Gentoo on the older variants, such as armv4 and armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3 cache? Lots of memory? Generally, anything that could be a bottleneck or severely increase the build time should be weighed against the potential number of users and possibly support dropped if there aren't enough developers or contributing users to maintain it. I.e., w/ MIPS, we don't support anything under the mips3 ISA, which includes DECStations (Debian does support those). Build times would just be tremendously slow and I haven't seen a lot of desire to support those. -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org 4096R/D25D95E3 2011-03-28 The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between. --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] splitting out arm keywords
On 07/09/14 05:09, Joshua Kinard wrote:
On 07/08/2014 21:48, Matthew Thode wrote:
arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard. By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm because stabilization takes forever then my
system may break because of both non-stabilized packages and because I
could be running armv6.
In any case I propose splitting out arm into armv4, armv5, armv6 and
armv7. armv8 seems to be here already as arm64.
Couldn't this be better handled with some profile work? These sound like
versions of Instruction Set Architectures. In the MIPS world, you have your
original ISAs, mips1 through mips4, then you have the newer variants of
mips32r* (branches from mips2) and mips64r* (branches from mips4). Anything
supporting mips4 could also support earlier ISAs. Throw in our three
supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can cover
all of this with just a single 'mips' keyword in the tree.
Yes, this should be done via the profiles. Code requiring later ISAs
and/or with extensions like thumb and neon will probably break on lower
ISAs. These should be masked on the profiles.
Is that similar to how these ARM variants work? Can an armv7 run code for
armv6 and earlier?
Its a bit more complicated that MIPS. You can test for yourself. I did
this via a chromebook (cortex-a15) using my hardened stages
(march=armv7a) available at mirror/experimental/arm/hardened, so you
can test too:
chrome ~ # echo int main() { return 0; } test.c
chrome ~ # gcc -march=armv7-a -o test test.c
chrome ~ # gcc -march=armv6 -o test test.c
chrome ~ # gcc -march=armv5 -o test test.c
chrome ~ # gcc -march=armv4 -o test test.c
chrome ~ # gcc -march=armv3 -o test test.c
/tmp/ccZjsI2O.s: Assembler messages:
/tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv3m -o test test.c
/tmp/cc1o59kQ.s: Assembler messages:
/tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2 -o test test.c
/tmp/ccmTNSyh.s: Assembler messages:
/tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2a -o test test.c
/tmp/ccTIXZ46.s: Assembler messages:
/tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc --version
gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So it looks like gcc can emit compat code back to armv4. This doesn't
necessarily mean that armv2 code won't run on an armv7a, but that
gcc-4.7.3-r1 can't produce such code, which is sufficient for our
purposes of masking.
Splitting 'arm' into four new keywords, on top of 'arm64' is just going to
give you guys major headaches later. You might even consider dedicated USE
flags for the arm subvariants and use those to control things in an ebuild
where applicable.
arm64 might as well be a totally different arch. There is no
compatibility between 32-bit and 64-bit arm variants --- at least not
that I know of, its a new arch that I'm just now getting familiar with.
On the other hand ppc and ppc64 should never have been split, but that's
another story.
We do not want keywords for every subarch otherwise we'll go crazy
stabilizing. We could adopt a policy of stabilizing on armv7a and when
a package doesn't build on a lower ISA, just mask it in the profiles.
I think this would be beneficial because of not all developers that want
to help with arm have or what all the sub-arches necessary. It also
allows us to move faster on stabilization because most of us have access
to armv7 a bit easier. This would take some pressure off of the people
doing stabilization for older sub-arches, but not much.
What's the support status of Gentoo on the older variants, such as armv4 and
armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3
cache? Lots of memory? Generally, anything that could be a bottleneck or
severely increase the build time should be weighed against the potential
number of users and possibly support dropped if there aren't enough
developers or contributing users to maintain it.
I.e., w/ MIPS, we don't support anything under the mips3 ISA, which includes
DECStations (Debian does support those). Build times would just be
tremendously slow and I haven't seen a lot of desire to support those.
Regarding MIPS, this isn't totally true. I'm willing to support mips-I
for embedded systems, although right now I'm just doing
Re: [gentoo-dev] splitting out arm keywords
On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
On 07/09/14 05:09, Joshua Kinard wrote:
On 07/08/2014 21:48, Matthew Thode wrote:
arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard. By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm because stabilization takes forever then my
system may break because of both non-stabilized packages and because I
could be running armv6.
In any case I propose splitting out arm into armv4, armv5, armv6 and
armv7. armv8 seems to be here already as arm64.
Couldn't this be better handled with some profile work? These sound like
versions of Instruction Set Architectures. In the MIPS world, you
have your
original ISAs, mips1 through mips4, then you have the newer variants of
mips32r* (branches from mips2) and mips64r* (branches from mips4).
Anything
supporting mips4 could also support earlier ISAs. Throw in our three
supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can
cover
all of this with just a single 'mips' keyword in the tree.
Yes, this should be done via the profiles. Code requiring later ISAs
and/or with extensions like thumb and neon will probably break on lower
ISAs. These should be masked on the profiles.
Is that similar to how these ARM variants work? Can an armv7 run code
for
armv6 and earlier?
Its a bit more complicated that MIPS. You can test for yourself. I did
this via a chromebook (cortex-a15) using my hardened stages
(march=armv7a) available at mirror/experimental/arm/hardened, so you
can test too:
chrome ~ # echo int main() { return 0; } test.c
chrome ~ # gcc -march=armv7-a -o test test.c
chrome ~ # gcc -march=armv6 -o test test.c
chrome ~ # gcc -march=armv5 -o test test.c
chrome ~ # gcc -march=armv4 -o test test.c
chrome ~ # gcc -march=armv3 -o test test.c
/tmp/ccZjsI2O.s: Assembler messages:
/tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv3m -o test test.c
/tmp/cc1o59kQ.s: Assembler messages:
/tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2 -o test test.c
/tmp/ccmTNSyh.s: Assembler messages:
/tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2a -o test test.c
/tmp/ccTIXZ46.s: Assembler messages:
/tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc --version
gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.
So it looks like gcc can emit compat code back to armv4. This doesn't
necessarily mean that armv2 code won't run on an armv7a, but that
gcc-4.7.3-r1 can't produce such code, which is sufficient for our
purposes of masking.
Splitting 'arm' into four new keywords, on top of 'arm64' is just
going to
give you guys major headaches later. You might even consider
dedicated USE
flags for the arm subvariants and use those to control things in an
ebuild
where applicable.
arm64 might as well be a totally different arch. There is no
compatibility between 32-bit and 64-bit arm variants --- at least not
that I know of, its a new arch that I'm just now getting familiar with.
On the other hand ppc and ppc64 should never have been split, but that's
another story.
We do not want keywords for every subarch otherwise we'll go crazy
stabilizing. We could adopt a policy of stabilizing on armv7a and when
a package doesn't build on a lower ISA, just mask it in the profiles.
I think this would be beneficial because of not all developers that want
to help with arm have or what all the sub-arches necessary. It also
allows us to move faster on stabilization because most of us have access
to armv7 a bit easier. This would take some pressure off of the people
doing stabilization for older sub-arches, but not much.
What's the support status of Gentoo on the older variants, such as
armv4 and
armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3
cache? Lots of memory? Generally, anything that could be a
bottleneck or
severely increase the build time should be weighed against the potential
number of users and possibly support dropped if there aren't enough
developers or contributing users to maintain it.
I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
includes
DECStations (Debian does support those). Build times would just be
tremendously slow and I haven't seen a lot of desire to support those.
Regarding MIPS,
Re: [gentoo-dev] splitting out arm keywords
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On 07/08/2014 09:48 PM, Matthew Thode wrote: arm has a historical problem with stabilization, while keywording doesn't require access to all arm sub-arches the problem with the stabilization slowness causes running a full ~arm to become hard. By that I mean that if someone keywords something for arm because it works on armv7 and I run ~arm because stabilization takes forever then my system may break because of both non-stabilized packages and because I could be running armv6. I admit the stabilization policy could use some work, however, arm isn't even the slowest of the minor arches. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. Just no. no. We support ~5 arm versions, and most of those can run softfloat, softfp, and hardfloat, all of which need testing. We are working on revising the stabilization requirements to be less stringent, but we are not splitting the arm team into 15 teams. I think this would be beneficial because of not all developers that want to help with arm have or what all the sub-arches necessary. It also allows us to move faster on stabilization because most of us have access to armv7 a bit easier. This would take some pressure off of the people doing stabilization for older sub-arches, but not much. We have devices available to all developers for all supported arches, if you were even on the arm team, you would know this. Some issues that need solving are as follows. [hard|soft]float differences. what stabilization means would need to be clarified a bit here. additional overhead of multiple arm teams Might be missing some points, but that's the main stuff I think Maybe you should actually join the arm team and learn some of this really critical stuff that you are ignoring rather than just making insane suggestions on the ML? Thanks, Zero_Chaos Arm Team Lead -BEGIN PGP SIGNATURE- Version: GnuPG v2 Comment: Using GnuPG with Thunderbird - http://www.enigmail.net/ iQIcBAEBAgAGBQJTvXBlAAoJEKXdFCfdEflKJxcP/1XujQ5lMEiEAm1qBZ+HWWLZ CqVrLeekrSYAT8vbfMeVO2b5Fpj4JruXInIm3WBozBRVI+r9Y2e4v8hS6bMKn/D6 L7C+29Lb0xnLJqQrIw/bR/lQxxuoIbrtmVMQxBaNese0pwOOAyYHG3EnLEIuMA2R sqh6RNhWIfPTdkOpeZAPo/Ql2z7WxxPnKDPP8w0/J0Hdhw3zrJCXlDfUq7g/RvBW 4jQd+Rabfla6BLQREipgdfZEHnaqH7KeJn7OkadRR77GKHkMgkz+aTgo0608FjEg HCmQ5cjWa6ZrKjbN9PZKEHcAuECR/Jo1Ro/Ybjxp1x9npQEaj4Zesu8QcoTP1UvO 67e3koGQ5C4wX47bnbR8GwZrPRCeO5+i40WKN6OB2qfK67LoedzMuzmsvRZN34yD 6NMlOaMP/kNJ8ISmj8y3Lf/21NeqRx4lVh4YUauUWE2Q48ckJDSBb5UXjkB+g+8T ra6yUNqUnJJVFnl+0gjS3X0TTDTBbfJHs5f9E2wd5cotGKAOaYjWF6WfSo3WSQMi sqADhiLKNrDOAqRBNkXGTg8S8d9YzoWLcfshETrT+FzYHmN9X+VZmwXUc4Aga9GM xC+AMzeBLX2zO/om5/u8qpmjZrx/B+57Lf6NSY+BJJOx6Vi8CvDMw0yF5kcTZYQq JNYq6FsIt8B9QUxgWs06 =7mPV -END PGP SIGNATURE-
Re: [gentoo-dev] splitting out arm keywords
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
09.07.2014 20:10, Manuel Rüger ?:
On 07/09/2014 01:40 PM, Anthony G. Basile wrote:
On 07/09/14 05:09, Joshua Kinard wrote:
On 07/08/2014 21:48, Matthew Thode wrote:
arm has a historical problem with stabilization, while keywording
doesn't require access to all arm sub-arches the problem with the
stabilization slowness causes running a full ~arm to become hard. By
that I mean that if someone keywords something for arm because it works
on armv7 and I run ~arm because stabilization takes forever then my
system may break because of both non-stabilized packages and because I
could be running armv6.
In any case I propose splitting out arm into armv4, armv5, armv6 and
armv7. armv8 seems to be here already as arm64.
Couldn't this be better handled with some profile work? These sound
like
versions of Instruction Set Architectures. In the MIPS world, you
have your
original ISAs, mips1 through mips4, then you have the newer variants of
mips32r* (branches from mips2) and mips64r* (branches from mips4).
Anything
supporting mips4 could also support earlier ISAs. Throw in our three
supported ABIs (o32, n32, n64), and machine-specific curiosities (SGI,
Cobalt, Yeelong/Loongson, etc), and life can be quite fun. But we can
cover
all of this with just a single 'mips' keyword in the tree.
Yes, this should be done via the profiles. Code requiring later ISAs
and/or with extensions like thumb and neon will probably break on lower
ISAs. These should be masked on the profiles.
Is that similar to how these ARM variants work? Can an armv7 run code
for
armv6 and earlier?
Its a bit more complicated that MIPS. You can test for yourself. I did
this via a chromebook (cortex-a15) using my hardened stages
(march=armv7a) available at mirror/experimental/arm/hardened, so you
can test too:
chrome ~ # echo int main() { return 0; } test.c
chrome ~ # gcc -march=armv7-a -o test test.c
chrome ~ # gcc -march=armv6 -o test test.c
chrome ~ # gcc -march=armv5 -o test test.c
chrome ~ # gcc -march=armv4 -o test test.c
chrome ~ # gcc -march=armv3 -o test test.c
/tmp/ccZjsI2O.s: Assembler messages:
/tmp/ccZjsI2O.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv3m -o test test.c
/tmp/cc1o59kQ.s: Assembler messages:
/tmp/cc1o59kQ.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2 -o test test.c
/tmp/ccmTNSyh.s: Assembler messages:
/tmp/ccmTNSyh.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc -march=armv2a -o test test.c
/tmp/ccTIXZ46.s: Assembler messages:
/tmp/ccTIXZ46.s:45: Error: selected processor does not support ARM mode
`bx lr'
chrome ~ # gcc --version
gcc (Gentoo Hardened 4.7.3-r1 p1.4, pie-0.5.5) 4.7.3
Copyright (C) 2012 Free Software Foundation, Inc.
This is free software; see the source for copying conditions. There
is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
PURPOSE.
So it looks like gcc can emit compat code back to armv4. This doesn't
necessarily mean that armv2 code won't run on an armv7a, but that
gcc-4.7.3-r1 can't produce such code, which is sufficient for our
purposes of masking.
Splitting 'arm' into four new keywords, on top of 'arm64' is just
going to
give you guys major headaches later. You might even consider
dedicated USE
flags for the arm subvariants and use those to control things in an
ebuild
where applicable.
arm64 might as well be a totally different arch. There is no
compatibility between 32-bit and 64-bit arm variants --- at least not
that I know of, its a new arch that I'm just now getting familiar with.
On the other hand ppc and ppc64 should never have been split, but that's
another story.
We do not want keywords for every subarch otherwise we'll go crazy
stabilizing. We could adopt a policy of stabilizing on armv7a and when
a package doesn't build on a lower ISA, just mask it in the profiles.
I think this would be beneficial because of not all developers that
want
to help with arm have or what all the sub-arches necessary. It also
allows us to move faster on stabilization because most of us have
access
to armv7 a bit easier. This would take some pressure off of the people
doing stabilization for older sub-arches, but not much.
What's the support status of Gentoo on the older variants, such as
armv4 and
armv5 stuff? How fast is the CPU clock on those? Do they include L2/L3
cache? Lots of memory? Generally, anything that could be a
bottleneck or
severely increase the build time should be weighed against the potential
number of users and possibly support dropped if there aren't enough
developers or contributing users to maintain it.
I.e., w/ MIPS, we don't support anything under the mips3 ISA, which
includes
DECStations (Debian does support those). Build times would just be
tremendously
[gentoo-dev] splitting out arm keywords
arm has a historical problem with stabilization, while keywording doesn't require access to all arm sub-arches the problem with the stabilization slowness causes running a full ~arm to become hard. By that I mean that if someone keywords something for arm because it works on armv7 and I run ~arm because stabilization takes forever then my system may break because of both non-stabilized packages and because I could be running armv6. In any case I propose splitting out arm into armv4, armv5, armv6 and armv7. armv8 seems to be here already as arm64. I think this would be beneficial because of not all developers that want to help with arm have or what all the sub-arches necessary. It also allows us to move faster on stabilization because most of us have access to armv7 a bit easier. This would take some pressure off of the people doing stabilization for older sub-arches, but not much. Some issues that need solving are as follows. [hard|soft]float differences. what stabilization means would need to be clarified a bit here. additional overhead of multiple arm teams Might be missing some points, but that's the main stuff I think -- -- Matthew Thode (prometheanfire) signature.asc Description: OpenPGP digital signature
