[Slackbuilds-users] RFC: qemu and aqemu
rworkman at slackbuilds.org
Fri Feb 3 21:37:13 UTC 2012
On Fri, 3 Feb 2012 22:16:55 +0100
Matteo Bernardini <matteo.bernardini at gmail.com> wrote:
> hope anybody don't mind if I share some thoughts on this :D
Sure, that's fine - otherwise, I wouldn't have CC'd the list :)
> 2012/2/3 Robby Workman <robby at rlworkman.net>:
> > First, how about a symlink at /usr/bin/qemu-kvm pointing to
> > /usr/bin/qemu-system-x86_64, i.e.:
> > ( cd $PKG/usr/bin ; ln -s qemu-system-x86_64 qemu-kvm )
> > This is so that e.g. aqemu can easily find it without the user
> > having to manually tell it where the KVM-equivalent binary is
> > located. I don't think there's any downside to this, and in fact,
> > if it were the only change I had, I'd just make it in our repo and
> > be done with it. However...
> I have the qemu-system-x86_64 binary linked to just "kvm", for using
> it with libvirt: I know it's another example of Red Hat
> customizations, but I remember a discussion of not much time ago on
> LKML in which Pekka Enberg renamed his new in-kernel kvm emulator
> kvm-tool to follow this "standard"...
> this way is also automatically found
Yes, similar to that is what aqemu does. It looks for both "kvm"
and "qemu-kvm" binaries, hence my suggestion of linking it to
"qemu-kvm" in the script. Perhaps both is better...
> > The second suggested change is to strip the package down quite a
> > bit. Basically, I'd like to remove everything that's also shipped
> > with the regular qemu package so that there's no overlap. This
> > would mean that our qemu-kvm would (optionally) depend on our qemu
> > package. Any thoughts on this?
> I think the present state is optimal: qemu-kvm should be used in every
> case kvm processor extensions are available, while qemu can be useful
> in the few cases of needing virtualization on old processors (it's
> very uncommon today to have x86 processors with no virtualization
> extensions); frankly, I see no cases in which the use of both can be
Oh, I see. Good point. In other words, you don't want to have to
install the regular "qemu" package to get the keymaps and such, as
all you care about are x86* architectures. That's a fair point,
and so I guess I should withdraw the conflict removal portion. The
conflicts don't really hurt anything anyway.
That being the case, here's my modified suggestion:
( cd $PKG/usr/bin
mv qemu-system-x86_64 qemu-kvm
ln -s qemu-kvm kvm
This addresses the concern with overwriting qemu-system-x86_64 with
the non-kvm-by-default file from regular qemu.
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 198 bytes
Desc: not available
More information about the SlackBuilds-users