On Mon, 23 Sep 2013 15:57:33 +0200 Jan-Simon Möller <[email protected]> said:
> > > > 64bit os's come with a major cost in memory footprint for pointers... it's > > quite measurable. and that doesn't change the fact that: > > > > 1. arm is STILL 32bit and will be for a long time still. if tizen can't be > > built ON an arm platform (which is 32bit) then it can't self-host on arm... > > which is embarrassing. > > We have to differ here ... > > a) > The request was to drop the tools for x86@32bit and just use the tools on > x86@64bit. Those tools are built/shipped for non-tizen distributions. > That being said, I'm not in favour of dropping it. > I know it is a maintainance burden - but that actually _is_ part of the game. > And if we cannot do this for our own tools ... as per my mail - i believe the issue is at least partly qemu memory mapping issue on 32bit (some kind of collission of mappings i think), and if it hapens on x86 it possibly/likely happens on arm too, so same issue if such a 32bit issue is dropped. :) > b) > To my best knownledge, the set of tools was never built for arm native (other > distros or tizen). Actually there was no reason to up to now; as we have more > powerful native hw, that _can_ be considered. But it means to check another > target. > > c) > Running the tizen tools on tizen iself is not yet done. Well, we should be > able to eat our own dogfood out of our own 3d-printed bowl. that was the point - we should be dogfooding... and we are not. and dropping 32bit support moves a step away from that, not towards it. :) -- Carsten Haitzler (The Rasterman) <[email protected]> _______________________________________________ General mailing list [email protected] https://lists.tizen.org/listinfo/general
