[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