[gentoo-dev] [RFC] subprofiles for ARM architecture

[gentoo-dev] [RFC] subprofiles for ARM architecture

[Raúl Porcel]

Hi,

The other day Markus(maekke) found an issue i encountered two years ago.
An app supports only a subarchitecture of the ARM architecture.

For those that don't know the ARM architecture, its an architecture
which is mostly used on embedded and/or mobile devices(cell phones,
mostly), also there's now some stuff called smartbooks(Efika MX
smartbook, Asus Transformer, etc...) and smarttops(Efika MX smarttop).

The problem is that during the history of the ARM architecture(according
to the wikipedia, the architecture was introduced back in 1981) there
has been some subarchitectures(the most available are armv4, armv4t,
armv5t, armv6j and armv7-a) which include new functions that is not
available on the previous subarchitecture. Something like SSE, SSE2,
SSE3, etc... but in arm is called SIMD, NEON, etc...

Apart from that, there are some apps that only work in one
subarchitecture because it uses some capabilities only available on that
subarchitecture and newer. Which is the case of valgrind. It only works
with armv7-a. Also there's www-client/chromium, which later versions
only work on >=armv6j.

With subprofiles we could keyword such packages, mask them globally on
arm and unmask it on the subprofile of the subarchitecture that supports it.

We build stage3s for the armv4t, armv5te, armv6j, armv7a
subarchitectures, and we'll make them use the profiles.

Thanks

Re: [gentoo-dev] [RFC] subprofiles for ARM architecture

[Arun Raghavan]

On 7 August 2011 17:20, Raúl Porcel <armin76@gentoo.org> wrote:
[...]
> With subprofiles we could keyword such packages, mask them globally on
> arm and unmask it on the subprofile of the subarchitecture that supports it.

I think this makes sense. What would the policy be on initial keywords
if upstream doesn't explicitly specify what sub-arches are supported?
Just enable on all till someone says it doesn't work or test on all of
them first or ...?

Cheers,
-- 
Arun Raghavan
http://arunraghavan.net/
(Ford_Prefect | Gentoo) & (arunsr | GNOME)

Re: [gentoo-dev] [RFC] subprofiles for ARM architecture

[Robin H. Johnson]

On Sun, Aug 07, 2011 at 01:50:42PM +0200, Raúl Porcel wrote:
> With subprofiles we could keyword such packages, mask them globally on
> arm and unmask it on the subprofile of the subarchitecture that supports it.
I suggest you go and look at the solution that was in place for MIPS
subarches as well to take that into consideration.

I think it still exists in: mips-sources, arcboot, arcload.
The latter two being bootloaders that need to be specifically configured
for the subarch else they just don't work.

I think the PPC64 folk also experimented for a while with something for
the Cell chip.

In general, +1 on the subprofile, but not so much on the masking,
unless cross-compile isn't an option at all.

-- 
Robin Hugh Johnson
Gentoo Linux: Developer, Trustee & Infrastructure Lead
E-Mail     : robbat2@gentoo.org
GnuPG FP   : 11AC BA4F 4778 E3F6 E4ED  F38E B27B 944E 3488 4E85

Re: [gentoo-dev] [RFC] subprofiles for ARM architecture

[Matt Turner]

On Sat, Aug 13, 2011 at 7:21 AM, Robin H. Johnson <robbat2@gentoo.org> wrote:
> On Sun, Aug 07, 2011 at 01:50:42PM +0200, Raúl Porcel wrote:
>> With subprofiles we could keyword such packages, mask them globally on
>> arm and unmask it on the subprofile of the subarchitecture that supports it.
> I suggest you go and look at the solution that was in place for MIPS
> subarches as well to take that into consideration.
>
> I think it still exists in: mips-sources, arcboot, arcload.
> The latter two being bootloaders that need to be specifically configured
> for the subarch else they just don't work.

We did have that, but I removed it because the profiles weren't
maintained. On MIPS, the purpose was to simply prevent things like
arcload from being installed on systems where arcload doesn't
work/isn't useful, which is only minimally useful itself.

ARM seems to have a much better reason for doing this -- packages
won't even compile on some subarchs.

Matt

Re: [gentoo-dev] [RFC] subprofiles for ARM architecture

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 848 bytes --]

On Saturday, August 13, 2011 01:41:54 Arun Raghavan wrote:
> On 7 August 2011 17:20, Raúl Porcel wrote:
> > With subprofiles we could keyword such packages, mask them globally on
> > arm and unmask it on the subprofile of the subarchitecture that supports
> > it.
> 
> I think this makes sense. What would the policy be on initial keywords
> if upstream doesn't explicitly specify what sub-arches are supported?
> Just enable on all till someone says it doesn't work or test on all of
> them first or ...?

we arent talking diff keywords ... there will still be just "arm".  the 
simplest approach is probably fine: don't worry about masking unless someone 
complains or the dev in question feels like digging into things.  it's not 
like having the package generally available will cause people any additional 
problems ...
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]

Re: [gentoo-dev] [RFC] subprofiles for ARM architecture

[Mike Frysinger]

[-- Attachment #1: Type: Text/Plain, Size: 1103 bytes --]

On Sunday, August 07, 2011 07:50:42 Raúl Porcel wrote:
> The problem is that during the history of the ARM architecture(according
> to the wikipedia, the architecture was introduced back in 1981) there
> has been some subarchitectures(the most available are armv4, armv4t,
> armv5t, armv6j and armv7-a) which include new functions that is not
> available on the previous subarchitecture. Something like SSE, SSE2,
> SSE3, etc... but in arm is called SIMD, NEON, etc...
> 
> Apart from that, there are some apps that only work in one
> subarchitecture because it uses some capabilities only available on that
> subarchitecture and newer. Which is the case of valgrind. It only works
> with armv7-a. Also there's www-client/chromium, which later versions
> only work on >=armv6j.
> 
> With subprofiles we could keyword such packages, mask them globally on
> arm and unmask it on the subprofile of the subarchitecture that supports
> it.
> 
> We build stage3s for the armv4t, armv5te, armv6j, armv7a
> subarchitectures, and we'll make them use the profiles.

makes sense to me
-mike

[-- Attachment #2: This is a digitally signed message part. --]
[-- Type: application/pgp-signature, Size: 836 bytes --]