qemu-devel
[Top][All Lists]
Advanced

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

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


From: Anthony Liguori
Subject: Re: [Qemu-devel] [PATCH] guest agent: qemu-ga daemon
Date: Sat, 23 Jul 2011 14:14:27 -0500
User-agent: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.2.17) Gecko/20110516 Lightning/1.0b2 Thunderbird/3.1.10

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.

Regards,

Anthony Liguori



Alex






reply via email to

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