[PlanetCCRMA] Gone virtually Meego 1.1 in Fedora -- lots of questions....

Niels Mayer nielsmayer at gmail.com
Sun Oct 24 09:42:27 PDT 2010


I just got Meego 1.1 SDK up and running on my Fedora12 desktop, courtesy of

"yum install kqemu qemu-kvm libvirt-client libvirt"
 &&
http://wiki.meego.com/SDK/Docs/1.1/Getting_started_with_the_MeeGo_SDK_for_Linux
 &&
http://www.exerciseforthereader.org/PCBSD/PCBSD8_under_qemu-kvm.html

(essential in the above is that RPMFusion "metapackage" kqemu will
install the appropriate kernel-dependent module, e.g.
kmod-kqemu-2.6.32.21-168.fc12.x86_64 from rpmfusion-free-updates )

So I can now from my 2.6.32.21-168.fc12.x86_64 desktop cut/paste
"root at meego-netbook-sdk:~# uname -a
Linux localhost.localdomain 2.6.35~rc6-134.1-qemu #1 SMP PREEMPT Thu
Jul 29 10:40:24 UTC 2010 i686 i686 i386 GNU/Linux"
from a gnome-terminal running in the kvm, even though there's a tiny
little netbook/handheld emulator running somewhere on my desktop too.
Not sure why I'd want to use it for devel/admin when I can run any X
app via:

     ssh -f -Y root at localhost -p 6666 "exec dbus-launch gnome-terminal
>&/dev/null </dev/null

I still have a little
http://people.redhat.com/berrange/olpc/sdk/network-bridge.html
to work through. However so far, it's outrageously easy in a modern
linux to setup and tear down other virtual OSes, and the performance
is surprisingly good, at least when emulating a 32 bit atom on a 64
bit phenom II :-)

I was surprised&happy to see "SMP PREEMPT" output from my virtual Meego logs:

Oct 23 21:30:24 localhost klogd: [    0.000000] Linux version
2.6.35~rc6-134.1-qemu (abuild at build16) (gcc version 4.5.0 20100414
(MeeGo 4.5.0-1) (GCC) ) #1 SMP PREEMPT Thu Jul 29 10:40:24 UTC 2010

Seems like all that's missing between this solution and my "meegolem"
hack of adding Fedora RPMFusion and PlanetCCRMA app/lib/devel
repositories to Meego is the "RT" from the CCRMA realtime kernel? Or
is Meego 1.1 already fully realtime capable and the message just omits
"RT" ?
What aspects of http://lwn.net/Articles/319544/ are in Meego 1.1?

Is this just a side-effect of modern linux kernels adopting the
preempt/rt patches:
http://events.linuxfoundation.org/2010/linuxcon-brasil/pt/gleixner ?
Does this mean, in the future, that separate realtime kernels as
provided for Fedora/Ubuntu distros will no longer be needed? And that
we'll be able to configure our systems for RT usage as needed?

Question: In a KVM/qemu environment, would I still be able to use all
the goodness the PREEMPT features of my virtual Meego 1.1 provide for
audio/media usage?

Next step -- try out "Meegolem" hack (
http://lalists.stanford.edu/lau/2010/09/0480.html
http://lalists.stanford.edu/lau/2010/09/0502.html ) on KVM'd Meego 1.1
and see how well "virtualized" media applications work. And figure out
http://libvirt.org/formatdomain.html#elementsSound to see if there's a
way of allocating a specific soundcard for use by
jack-audio-connection-kit (although I did get netjack running
previously in 1.0, so could use jackd on the "host" OS and netjack on
the virtualized one with some SSH tunneling).

However the netjack solution doesn't really scratch the realtime itch,
and SSH tunnelling across localhost isn't exactly the definition of
performance. The question is, would it work to have the the OS with
preempt features running in a KVM; using jackd in that OS to gain
realtime and exclusive access to specific media hardware. Would that
provide realtime performance for just the apps needing it, running in
the virtualized realtime kernel, or would that be a recipe for
disaster?

-- Niels
http://nielsmayer.com

PS: Assuming there was a way for me to grant exclusive access to a
particular soundcard from a given KVM OS, would I be able to
experiment with writing/changing an ALSA device driver for a
particular device within the  "experimental OS" running in KVM, while
using all my other devices/desktop as normal, without fear of
crashes/hangs/etc? Is this a sensible development strategy?



More information about the PlanetCCRMA mailing list