On 23.07.2011, at 21:14, Anthony Liguori wrote: > On 07/23/2011 01:34 PM, Alexander Graf wrote: >> >> On 23.07.2011, at 18:43, Michael Roth wrote: >> >>> On 07/23/2011 11:10 AM, Anthony Liguori wrote: >>>> On 07/23/2011 11:06 AM, Michael Roth wrote: >>>>> On 07/23/2011 05:07 AM, Alexander Graf wrote: >>>>>> >>>>>> On 20.07.2011, at 22:19, Michael Roth wrote: >>>>>> >>>>>>> This is the actual guest daemon, it listens for requests over a >>>>>>> virtio-serial/isa-serial/unix socket channel and routes them through >>>>>>> to dispatch routines, and writes the results back to the channel in >>>>>>> a manner similar to QMP. >>>>>>> >>>>>>> A shorthand invocation: >>>>>>> >>>>>>> qemu-ga -d >>>>>>> >>>>>>> Is equivalent to: >>>>>>> >>>>>>> qemu-ga -m virtio-serial -p /dev/virtio-ports/org.qemu.guest_agent.0 \ >>>>>>> -f /var/run/qemu-ga.pid -d >>>>>>> >>>>>>> Signed-off-by: Michael Roth<mdr...@linux.vnet.ibm.com> >>>>>> >>>>>> A rebase on top of current HEAD gave me the following on openSUSE 11.1 >>>>>> PPC: >>>>>> >>>>>> >>>>>> agraf@lychee:/home/agraf/release/qemu> make >>>>>> CC qemu-ga.o >>>>>> qemu-ga.c:40: error: expected specifier-qualifier-list before ‘GSocket’ >>>> >>>> GIO is fairly new. It may not be available on openSUSE. >>>> >>>> Mike, you probably need to do a configure test for GIO and if it's not >>>> present, don't build qemu-ga. >>> >>> It should've failed the glib probe in that case. I think we might need a >>> compile test to catch this GSocket issue. >>> >>> Rather than building qemu-ga when possible, should we just go ahead and add >>> a configure option and only run the probes when it's set? At least until >>> QMP/QEMU start formally using glib? If so, on or off by default? >> >> In general, I like the workflow of adding a feature with default off and >> then enabling it after it has been in for a couple of weeks. Since this got >> pushed so late for 0.15, I'd personally prefer to see it as preview >> (disabled by default) in 0.15 and only enabled by default if the >> requirements are there on 0.16. > > The only way something like this gets tested is to default it on. > > We default off'd the I/O thread even after years we still don't have it > enabled. > > With respect to 0.15, this bit of code is totally isolated from everything > else. Worst case scenario, we just disable it on platforms where it doesn't > work. It presents no real risk to the stability of the release.
As you've seen, it can break builds. Why not wait for 0.16? The code came in more than 2 months after the soft feature freeze, which was specifically for big features like this, no? Alex