On Thu, Feb 21, 2013 at 03:39:44PM +0100, Paolo Bonzini wrote: > Il 21/02/2013 15:30, Michael Tokarev ha scritto: > > 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? > > That you list all the build products in the Makefile, where they should be. > > > 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. > > Since we do not ship udev rules, we are really shipping it for the user > to call it. How it does that, we don't care. > > > 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. > > sbindir would be more correct than libexecdir. > > The latest fad for udev is to put helpers in $prefix/lib/udev (not > $libdir, because there's no 32/64-bit differentiation). > > Perhaps the best solution is to add --with-qemu-ga-dir=... and default > it to $bindir. Then distros that ship udev rules can move it to > /usr/lib/udev, distros that ship an initscript can move it to /usr/sbin > or wherever they prefer.
Seem reasonable to me. If qemu-ga isn't a TOOL or HELPER, it probably doesn't make sense to think up a new group to configure it until we have other examples to consider. > > >> 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). > > I'm talking about virtfs-proxy-helper. > > Paolo > >
