On Thu, Feb 21, 2013 at 8:30 AM, Michael Tokarev <m...@tls.msk.ru> wrote: > 21.02.2013 17:35, Paolo Bonzini wrote: >> Il 16/02/2013 19:28, Michael Tokarev ha scritto: >>> This patch does 3 things: >>> >>> 1. Renames HELPERS-y Makefile variable to HELPERS >>> 2. Moves its definition from Makefile to configure >> >> I prefer to have more decisions in Makefile than configure, but this >> wouldn't block the patch. What we have now is a mess anyway. > > What's the difference between checking for host OS type being > in makefile or configure? > > Note that in this very case current condition is a bit wrong: > it should not only depend on linux but also about presence of > softmmu targets (which this patch fixes too). > >>> 3. Moves qemu-ga binary from TOOLS to HELPERS. >>> >>> The effects are: >>> >>> 1. qemu-ga binary is now installed into libexecdir, not bindir. >>> This is the main effect/motivation of this patch, -- this binary >>> has no business being in a public binary directory, it is a system >>> helper which must be run by a system startup script or some event >>> daemon. >> >> There is one difference, and an important one: qemu-ga does appear in >> system-wide configuration files, while qemu-bridge-helper does not. In >> this sense, qemu-ga is not a helper executable. > > Well, it definitely is not a user-callable binary. In that sence it is a > "system helper" (as opposed to "qemu helper" for qemu-bridge-helper). Ie, > either sbin or libexec, but not bin. There's no sbindir handling currently, > -- > neither in makefile nor in configure, only "TOOLS" and "HELPERS" variables.
Just to throw my two cents in here, I agree with Paolo. I don't know of any programs started by init scripts that live in /usr/libexec. I've grepped on a Gentoo box, RHEL5 and RHEL6 for libexec in /etc/init.d and none of them have any references. So it seems like a better place is /usr/bin (I could see /usr/sbin but I thought that was also targeted by the /usr merge to go away and just have it all in /usr/bin). > >> I have no idea how virtfs-proxy-helper would work, but I suspect that a >> better design would have QEMU spawning it, just like qemu-bridge-helper. > > QEMU can't spawn it, it is spawned in *guest* by a startup script or some > event daemon (such as systemd or udev). > > Thanks, > > /mjt > -- Doug Goldstein
