On Wed, 2020-10-07 at 21:45 -0400, Laine Stump wrote:
It is *definitely* less hacky to use <qemu:commandline> than to carry
your own local patch on top of the libvirt source, which would force
you to always build your own libvirt binaries, and rebase your patch
every time upstream libvirt changed code that touched the same place.
Although <qemu:commandline> isn't "Supported" (Capital "S"
- in the
sense that a vendor providing paid technical support for a system
using libvirt won't officially commit themselves to solving any
problem you may have associated with use of <qemu:commandline>, and
the options you provide there *could* disappear from qemu), it is
"supported" (small "s" - in the sense that libvirt has no plans to
remove <qemu:commandline>, and it is used by other people so if it
becomes broken it will surely get fixed).
Using <qemu:commandline> will take 10 minutes of your time right now,
and then you'll never have to think about it ever again (until/unless
QEMU removes the x-vga option). Using your own custom build of
libvirt that carries a locally written patch will continue to be a
burden every time you upgrade libvirt until the end of time.
Thanks for the detailed instructions, I had missed the alias part
before, I don't know if that was where I was going wrong? The
<qemu::commandline> part would just disappear when I hit apply.
The original patch only took me 10mins at most, yeah it shows, but
worked straight away. I've been running Gentoo unstable for the last
20 years, patch rebasing isn't really a problem! :-) I'm very used to
creating patches for new features and bug fixes as I need to, it's part
of my usual update process. I must have written thousands over the
years. I've been trying to make a bit of effort to get some pushed
upstream, rather than having them sit in an overlay or
"portage/patches".
It is taking some time and effort to get the validation working, but I
don't think it's a waste of time. I'm getting better familarised with
the code which isn't a bad thing, and might allow me to make more
appropriate contributions in the future. Maybe I'll try fixing the
"isapc" machine type?! ;-)