What about a multi-arch RPM approach, where binaries for multiple architectures are contained in a single RPM, but where only the arch specific variant is installed?
This would avoid the size increase of a multi-arch ELF approach, and avoid the (possible) performance loss and (possible) execution problems of a (not yet mature) intermediate format. -Sander On Dinsdag 31 Mei 2011 11:25 CEST, Carsten Munk <[email protected]> wrote: > Yes, indeed - I've been fed the usual JVM and JIT knowledge through my > university education like many others, but this isn't the approach > taken in MeeGo currently as we have to write C++ for our native Qt > Quick extensions and we don't have a JVM on each device. > > I feel that LLVM could give some good opportunities for MeeGo in this area. > > BR > Carsten Munk > > 2011/5/31 Zhang, Zheng <[email protected]>: > > Android has done most of such jobs via JVM. > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Carsten Munk > > Sent: Tuesday, May 31, 2011 2:11 PM > > To: meego-dev > > Subject: [MeeGo-dev] MeeGo app model in 2012: Rethinking the MeeGo app > > model to be more platform agnostic > > > > Hi, > > > > One of the disadvantages of MeeGo is that unlike Android and other OS'es, > > we don't provide a way for developers to provide one MeeGo compliant RPM > > for typical MeeGo applications+extensions that will run on all MeeGo > > devices, no matter if it is IA, ARM, MIPS. I'd like to spark a technical (+ > > compliance) discussion on if we can somehow make this reality. > > > > I'd like a world where it matters less what architecture a MeeGo device > > runs, or even specific optimization flags/architectures not in line with > > what meego.com builds when it comes to compliance, allowing more > > flexibility in hardware choice and hardware directions over the long term. > > > > Opinions that this isn't feasible is more than welcome :) Since we're all > > about fast innovation now, here's one idea to think about. > > > > With the news of Qt5 the new future application model[1] is clear. It > > motivates that 'While offering all of the power of native Qt using > > C++, the focus should shift to a model, where C++ is mainly used to > > implement modular backend functionality for Qt Quick.'. This will cause a > > development model for MeeGo API apps along lines of: > > > > * QML applications, platform agnostic, distributed as 'noarch' RPM > > packages. Contains QML/js files, resources, etc. > > * Qt Quick modules, platform agnostic, written in QML/js, distributed as > > 'noarch' RPM packages (think widget sets, etc) > > * C++ Qt Quick modules, platform specific, distributed as > > i586/armv7hl/mips/etc RPM packages. Contains compiled native code specific > > to a target processor. Typically shared objects. > > > > As you can see, we're 2/3 there to where it essentially doesn't matter what > > the underlying device runs, except that it provides certain APIs/runtimes > > for the QML apps to use. Having a MeeGo Core that we can optimize towards > > specific use cases and hence a wider market for MeeGo to be used in. > > > > I'd like to propose that we go to a model where we have one MeeGo API SDK > > with one toolchain that targets the MeeGo platform, no matter the hardware > > architecture. This means, take C++ Qt Quick modules and build them into a > > platform agnostic format (intermediate language) that is then translated by > > an application store or by device itself into native code, which is then > > run on the device. > > > > Google has already been working on a similar approach for their Native > > Client work, based on the LLVM intermediate format[2] and I think this is > > plausible to do for MeeGo too in a similar fashion in a short timeframe. > > They have been working on shared objects as well[3]. > > > > Now, there are some issues to be discussed and I'll list some of them: > > > > 1) Performance loss - will there be any noticable loss in application > > performance? Will it be mitigated by the fact the MeeGo platform + Qt stack > > is optimized to the target as that's where the real work goes on usually? > > 2) Will ARM or IA/Atom specific optimizations be lost if LLVM is used? > > 3) Licensing issues (GPLv3/LLVM license/etc?) > > 4) Security implications/signing issues/etc > > 5) Obfuscation and reverse engineering implications of IL being used. > > 6) Compliance implications > > 7) Hardware specific extensions > > > > And last of all: > > > > Is it plausible to have a C++ extension in LLVM intermediate language > > (targetted towards a fictional machine description) that links without > > issue into the native Qt stack across architectures? > > > > Let me hear your thoughts - I think this could be a significant platform > > win. > > > > BR > > Carsten Munk > > > > [1] http://labs.qt.nokia.com/2011/05/09/thoughts-about-qt-5/ > > [2] http://nativeclient.googlecode.com/svn/data/site/pnacl.pdf > > [3] http://www.chromium.org/nativeclient/pnacl > > _______________________________________________ > > MeeGo-dev mailing list > > [email protected] > > http://lists.meego.com/listinfo/meego-dev > > http://wiki.meego.com/Mailing_list_guidelines > > > _______________________________________________ > MeeGo-dev mailing list > [email protected] > http://lists.meego.com/listinfo/meego-dev > http://wiki.meego.com/Mailing_list_guidelines _______________________________________________ MeeGo-dev mailing list [email protected] http://lists.meego.com/listinfo/meego-dev http://wiki.meego.com/Mailing_list_guidelines
