Liberally forking this thread so we can start a discussion - could someone involve the ARM toolchain guys too as we should kickstart this work asap?
2010/10/24 Arjan van de Ven <[email protected]>: > On 10/24/2010 11:13 AM, [email protected] wrote: >>> >>> ________________________________________ >>> From: Thiago Macieira [[email protected]] >>> Sent: Saturday, October 23, 2010 6:48 PM >>> >>>> Harri: >>>> I propose, that we don't specify softfp as the baseline for complience, >>>> but rather say that current softfp is temporary phase and we will move >>>> to hardfp as soon as possible, potentially in 1.1 update if we will have >>>> such a thing. >>> >>> I think that's a bad idea. We can't switch to hardfp without a full >>> binary >>> compatibility break. So it should be done at the new release, 1.2. >>> >>> That also means devices upgrading from MeeGo 1.1 to 1.2 will need a full >>> reinstall/flashing. No applications from any repository or store will >>> survive >>> and need to be recompiled. >> >> I think that we are not supposed to break binary compatibility between >> Meego 1.1 and 1.2 , so breaking at 1.2 is not good option at all ... >> >> So, in this case I propose that we do that in MeeGo 1.1.1 (or whatever is >> the right number for MeeGo 1.1 update). >> >> Imho, that will be the least painfull way for everybody, especially if we >> decide and communicate this now. Now the amount of code/applications >> that needs to be recompiled is still manageable. As well as the number of >> affected parties. > > 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. 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. * Organisationally, do we deprecate ARMv7 (softfp) and state it has been replaced with armv7hfp for 1.2? * 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. 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.. 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? Best regards, Carsten Munk Nokia N900 hardware adaptation maintainer. _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev
