As noted by Slashdot in http://slashdot.org/article.pl?sid=05/02/19/1538231&tid=190, qemu ebuild should include possibility to use qemu accelerator module (on x86 arch). Due to licensing issues, the modules should probably be set to manual download (Fetch). Module only works with qemu's CVS version.
I already contacted the author and I got the permission to have kqemu distributed within gentoo. Once the qemu-0.6.2 is release (due some days I think) you could have the qemu + kqemu just issuing: USE=kqemu emerge -u qemu
I've build qemu directly from CVS sources and it's working fine with kqemu. Because of license issues I recommend to use an USE flag "kqemu" for example and to set manual fetch restriction for the kqemu binary. The "kqemu" USE flag should be ignored, if the host computer isn't an x86-compatible (including 64bit).
Please have a look at my public overlay on dev.gentoo.org
Created attachment 55365 [details, diff] qemu-0.6.2.20050309.patch Luca, here's a patch for your current overlay ebuild. The changes: 1) CFLAGS are filtered rather than unset. (we dont compile with -g) 2) Supports QVM86, the GPLed kernel accelerator. See the announcement 2 days ago here http://lists.gnu.org/archive/html/qvm86-devel/2005-04/msg00000.html I'm currently up and running with QVM86 and everything is working well.
Created attachment 55366 [details] qvm86-20050405.tar.bz2 Since theres no release of qvm86 yet, heres a CVS snapshot.
I just lurk the qemu ml and I know about the qvm86 but I didn't test it yet. The idea of supporting both looks fine, could you please send me a diff -u of your changes so I could update the snapshot ebuild. If enough users want it I could think about adding a p.masked snapshot in the tree.
The ebuild diff is already attached as qemu-0.6.2.20050309.patch. A new ebuild in portage would be good.. it's always a pain having to find a bug report and download ebuilds. Anyway, the sooner people find problems, the sooner they'll be fixed! :)
diff -u is usable by patch and easyer to understand than plain diff... experimental ebuild usually stay in the developer devspace, so people interested can just poll those pages. I hope to have the time to get something in portage tomorrow.
Created attachment 55506 [details, diff] qemu-0.6.2.20050309-r1.ebuild.patch unified diff patch
I have an updated ebuild to the today snapshot but isn't working well If there is someone willing to have it (qvm86 and qemu snapshots + ebuild) just asks. I'll keep unsetting CFLAGS.
Tested the ebuild and works ok. One thing that seems to be missing though is an udev permission that gives the /dev/kqemu more lenient rights (maybe 660 with group users). Now if I modprobe kqemu the device is root-only. I hope they release final qemu-0.6.2 soon...
Probably I'll add an udev rule for it (to set it for the wheel group) if you have other ideas about that feel free to tell me
IMHO the wheel group is *only* for allowing su command, and should not be used for anything else. If you're thinking that allowing all "users" group to access the device is a bad idea and no existing groups seem to fill it (perhaps "video" or "tty" or even "games") then maybe you could just create a new group like "qemuvm" that would cover all (2 at the moment) qemu virtualizer kernel modules. Anyway, wheels role should not be expanded from pointing out users who can upgrade to root permissions.
Qemu 0.7.0 is out! Please include into portage tree :)
Let me test it today
*** Bug 90668 has been marked as a duplicate of this bug. ***
ebuild committed, qvm86 got removed pending release or stabilization (and a way to make it build in non exclusive way)
Apparently you left out the udev permission rule. For me, adding #kqemu kqemu:root:root:0666 to the rules is ok, but you might try something like #kqemu kqemu:root:users:0660 or even create a new group like "qemuvm" for this and say pkg_preinst() { enewgroup qemuvm } in the ebuild and add appropriately to udev permissions..
you are right! I'll add something soon
https://bugs.gentoo.org/show_bug.cgi?id=90925 contains a patch and a new ebuild which fixes a function-renaming-issue with kernels newer than 2.6.12-git4
That's not the right place to discuss the issue. Thank you for the headup anyway (better a relatively redundant information that no information)
