2010/11/30 <[email protected]>: > Hi, > > I went through the MeeGo 1.1 Compliance Specification > (v. 1.0.99.4) with people from Nokia MeeGo team. > > Comments we wanted to highlight: > > 1. Compliancy principles (and ABI), section 1.4.1.1. > The compliancy principles regarding ABI are not clear. Is the > target to have one ABI per CPU architecture (like ARM v7) or > are multiple (accepted) flavors possible (like ARM v7 hardfp > and ARM v7 softfp)?
> Additional questions > a) is the ABI promise over releases stated somewhere in the document? > b) how long an ABI is guaranteed to stay? > > Perhaps MeeGo API and source level compatibility would be adequate for > 1.1 and the (ARM) ABI story could be clarified for 1.2. specification. Admittedly we could need a 'minimum' requirement definition when it comes to 'architecture', so it's possible to have ABI-compatible subarchs (see further down). I originally contributed the part about ARM and 'softfp' and my argument is: * Application SDKs will target the minimum requirement of the architectures defined, so if the agreed baseline of MeeGo.com targets that, this is what you must support in your system. * What is currently the minimum requirement from MeeGo.com - your system will have to support ARMv7, VFPv3-D32 or Core2 / SSSE3 as minimum or your SDK made apps won't run. * Applications targetted against the MeeGo architectures must run on MeeGo compliant systems, so you can't have a MeeGo compliant system that uses an alternate ABI, such as hardfp. -> Why we need to specify it kinda exact in compliance. Your hardfp system wouldn't be compliant cos apps won't run on it. Perhaps we should name the architecture ARMv7-softfp already in 1.1 with a remark that there is no ABI promise of this architecture staying around. My definition of subarchs is RPM subarchs: This means, RPM knows that if your device is for example, i686, you can install i586 packages too. Zypper for example takes the most optimized package for your device based on capabilities. Regarding subarchs - at least what we've discussed so far for 1.2 ARM: * Compliance defines a baseline, ARMv7 hardfp, vfpv3-d16, the RPM architecture 'armv7hl' for the system. MeeGo.com baseline would then work on all known ARMv7 platforms. * ABI-compatible sub-architectures are allowed by compliance spec, standardizing such as 'armv7hln', which means 'uses NEON instructions'. Experiments will be done to auto-provide these packages from meego.com as well for the applications that matters . Like some distros provides i686 optimized packages. * Systems can be compiled towards anything above baseline, for example, armv7hln, or your own sub-architecture as long as you can still run armv7hl (baseline) architectures. This means vendors can optimize their MeeGo system towards anything they want, such as NEON, or future ABI-compatible innovations. * Compliant applications will be default armv7hl, but provided your device can handle it, repositories/app stores/etc can also offer armv7hln packages of the same application. This means application vendors can optimize applications if they have a benefit for it, without losing cross-platform ability. BR Carsten Munk _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
