Hi Alison, Your messages are very thoughtful :)
Last year I have worked on chroot and Qemu/VirtualBox. From my experience, chroot is too thin for such task while Qemu/VirtualBox is too heavy. In chroot, you have to deal with the daemon/server/resource conflict problems as you said. I have thought if the container concept is supported in official Linux kernel, it should be a good solution to boot up both MeeGo and Android. OpenVZ (http://en.wikipedia.org/wiki/OpenVZ) provides container, while you need to change the underlaying Linux kernel. Another option is using the hypervisor technology, such as Xen, to run MeeGo and Android in difference domains. Thanks -Haitao On Fri, Jan 21, 2011 at 03:04:16PM +0800, [email protected] wrote: > Niels Mayer writes: > > In http://www.markshuttleworth.com/archives/556 I note the following: > > Thanks for the provocative link to an article I'd missed. > > > Why can't the same be done for MeeGo handset, such that Android apps > > and MeeGo apps are available simultaneously from a MeeGo platform, > > Hmmm. What Shuttleworth precisely said in your quoted snippet was > [EMPHASIS mine] > > >> the Linaro team is going to build an Android environment on the > >> same kernel and toolchain that we collaborate on with Ubuntu. For > >> folks building devices, picking a board that's part of the Linaro > >> process means you'll be able to get EITHER an Ubuntu-style OR > >> Android-style core environment up and running > > I interpret Shuttleworth's statement to refer to either a dual-boot or chroot > approach to running Android apps alongside Ubuntu. In neither case are > Android apps running "on top of" MeeGo. Note that Maemo and MeeGo are, to > say the least, more similar than Android and Ubuntu, yet we are not running > unported Maemo apps "on top of" MeeGo, but alongside it as either a > dual-boot or chroot. (Here I'm ignoring, for example, Python-based apps > that are interpreted since I'm assuming that's not what you're talking about.) > > I've thought a great deal recently about how to get Android apps going "on > top of" MeeGo and have considered several approaches: > > 1. A virtual machine, probably Qemu, running an Android instance could host > Android apps. Advantage: porting the emulator that comes with the Linux > version of the Android SDK to MeeGo is probably not that hard. > Disadvantage: performance is not going to be great, resource utilization will > be bloated, hardware support may be iffy. And will MeeGo include Qemu? > (It certainly could since Qemu is kvm-based and mainline incorporates kvm, > but that doesn't mean it will.) > > 2. Android apps could talk to MeeGo kernel through a less-capable > compatibility layer (similar to the way that Wine that allows Windows apps to > run on Linux). Disadvantage: High maintenance and undoubtedly buggy. > > 3. We could create a port of the Dalvík JVM that runs on top of a patched > MeeGo kernel that is more like Android, which has different power management, > IPC and memory model in addition to the previously noted security framework > differences. Advantage: reasonable performance. Android patches to kernel > are arguably sound ideas. Disadvantages: disruptive to implement; puts > MeeGo at Open Handset Alliance's mercy for ongoing support; politically > impossible. > > 4. Port Dalvík but instead of patching MeeGo kernel, create a compatibility > layer that maps Android's {security, power management, memory management, > IPC} into standard Linux. I'm out of my depth commenting here, but I > suspect that this option might result in reasonable performance but would be > a hairy, buggy mess. > > 5. Source-code translation. It would be great to have a build-time solution > that would, presto, turn Android apps into ones that would compile on MeeGo. > Disadvantage: creating the translator is a forbidding task that would require > ongoing, expensive maintenance. Advantage: liable to produce stable, > decently performing result. > > The situation for WebOS looks much simpler, as it appears to be built on a > traditional Linux stack like MeeGo even though it, like Android, it has a > foreign body (here Webkit) stuck in the middle. Webkit runs on MeeGo, so > the path forward is clear. > > You won't be surprised to hear that I've been consulting with experts and > have started writing a whitepaper on this very topic. > > My immediate reaction is that a chroot solution is most viable in the short > term, but the question of QoS is a bit scary. In other words, if MeeGo > answers the phone, what happens if a call comes in while an Android app is > running? chroot and real-time seem fundamentally incompatible to me. > > I'd love to hear any thoughts about these issues from people who know more. > Also, is there is a better place to ask these questions than meego-community? > Sorry for the long message. > > -- > Alison Chaiken > MeeGo Technical consultant > Nokia Mobility Solutions > Sunnyvale CA > 650-279-5600 > [email protected] > http://exerciseforthereader.org/ > _______________________________________________ > MeeGo-community mailing list > [email protected] > http://lists.meego.com/listinfo/meego-community _______________________________________________ MeeGo-community mailing list [email protected] http://lists.meego.com/listinfo/meego-community
