Re: [Qemu-devel] [PATCH] guest agent: qemu-ga daemon

[Alexander Graf]

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<address@hidden>
>>>>>> 
>>>>>> A rebase on top of current HEAD gave me the following on openSUSE 11.1
>>>>>> PPC:
>>>>>> 
>>>>>> 
>>>>>> address@hidden:/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