[Slackbuilds-users] RFC: qemu and aqemu

[Robby Workman]

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
> 
> http://ompldr.org/vY20xaA/screen.png


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
> useful...


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.

-RW
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 198 bytes
Desc: not available
URL: <http://lists.slackbuilds.org/pipermail/slackbuilds-users/attachments/20120203/48078271/attachment.asc>