qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] [PATCH] move qemu-ga from bin to libexec dir, use $HELP


From: mdroth
Subject: Re: [Qemu-devel] [PATCH] move qemu-ga from bin to libexec dir, use $HELPERS
Date: Thu, 21 Feb 2013 09:16:24 -0600
User-agent: Mutt/1.5.21 (2010-09-15)

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
> 
> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]