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

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_L… && 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@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@localhost -p 6666 "exec dbus-launch gnome-terminal 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@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?