[libvirt] [PATCH] qemu: Search binaries in PATH instead of hardcoding /usr/bin
Daniel Veillard
veillard at redhat.com
Wed Jan 20 21:46:30 UTC 2010
On Wed, Jan 20, 2010 at 10:32:03PM +0100, Matthias Bolte wrote:
> 2010/1/20 Daniel Veillard <veillard at redhat.com>:
> > Pro: it's more flexible
> > Cons: it's less rigid
> >
> > :-)
> >
> > I think it's fine since in the majority of cases that code will be run
> > by libvirtd, which as a daemon will have a relatively well defined and
> > contained PATH . Like when a rogue shared library si available in some
> > common place that lead to very painful debugging when an user has a
> > problem, rather than the rather straighforward error about a missing
> > binary the current version. It's a bit of a double edged sword, but in
> > that case I think it's fine. But I could see how others could disagree
> >
> > ACK from my POV,
> >
> > Daniel
> >
>
> Actually this code will never be executed outside of libvirtd, because
> it's executed as part of the QEMU state driver startup only.
>
> Well, I wouldn't compare this to a "rogue shared library" or
> LD_PRELOAD stuff, because you can use virsh capabilities for example
> to see if it picks up unexpected QEMU binaries. So this shouldn't make
hum, that's true.
> debugging harder. You need to know where to look for information when
> debugging, that's right.
>
> Also this make libvirt behave more like the user expects it to. There
> were some people on the mailing list and on IRC lately that had
> problems with the hardcoding of /usr/bin. They expected libvirt to
> pick up their QEMU binaries in /usr/local/bin for example.
Okay :-)
Daniel
--
Daniel Veillard | libxml Gnome XML XSLT toolkit http://xmlsoft.org/
daniel at veillard.com | Rpmfind RPM search engine http://rpmfind.net/
http://veillard.com/ | virtualization library http://libvirt.org/
More information about the libvir-list
mailing list