>> >> I don't think this can be done at all. >> this will break all 3rd party apps and components, including codecs, plugins >> etc etc >> >> that's not something that's just ok to do easily or.. well really, ever. >> > > I agree that it is problematic, but even Linaro is moving in that > direction which means a lot of reference plugins/codecs on ARM side > will actually be hardfp in the future instead of softfp. The elephant > in the room is the fact that Nokia's Harmattan is moving/has moved to > hardfp too and that apps made for 1.1 ARMv7 softfp won't work on 1.2 > ARMv7 hardfp.
I think Carsten makes a strong point here, we're going to have to come to terms with hardfloat one way or another and its seems wiser to make the transition now as opposed to later when there is a larger installed base. > How exactly we would bootstrap this work and how/when it would/could > be included is something that should be discussed, so here's my > kickoff in this area to start a conversation: > > * The idea is to include support for a new architecture in MeeGo, like > we would do in case of a MIPS port of MeeGo, ie, bootstrap port is > done (Trunk compiled..), people are assigned to take care of bug > fixes, build capacity donated, approved by TSG at some point. This > would be ARMv7 hardfp, let's call it armv7hfp. +1 > > * Organisationally, do we deprecate ARMv7 (softfp) and state it has > been replaced with armv7hfp for 1.2? I think this is moving too fast. Can't we keep separate repos for a while? Give people some more time before we End Of Life softfloat? > > * To do this, technically, we'd have to bootstrap the port like we did > with MeeGo ARMv5. Due to the softfp/hard conflict, we cannot reuse any > of the ARMv7 binaries. Back then we started with MeeGo ARMv5, we used > Fedora ARM to bootstrap a base system. > > Since there's no hardfp port of Fedora ARM, I propose that we > bootstrap using debian hardfp port, debian-armhf, or using Linaro's > work in this area with Ubuntu. Having Linaro involved could be a good > thing. +1 Are there resources to maintain this kind of thing and its eventual changes inside MeeGo? Who are we identifying as potential contributors? How will we integrate Linaro changes? Are they willing to help there? > > The reason for this is that rpmbuild and other tools exist for this > platform as well and hence we can do a set of binary armv7hardfp RPMs > we can use for starting proper OBS compiles of the MeeGo Trunk. > > Support for OBS+RPM tools for armv7hardfp 'architecture' would be > needed and potentially qemu-arm support.. Now you're starting to talk about a lot of work and resources. > > Of course this means our 1.1 developer story sucks from a binary > compat point of view, but the risk is that we'll be tied forever to > softfp instead.. > > And throwing this in the discussion too: -mfpu=neon or not in MeeGo > ARMv7 hardfp? Jeremiah _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
