qemu-devel
[Top][All Lists]
Advanced

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

[Qemu-devel] Re: [PATCH v1 00/14]: Initial QObject conversion


From: Luiz Capitulino
Subject: [Qemu-devel] Re: [PATCH v1 00/14]: Initial QObject conversion
Date: Mon, 5 Oct 2009 10:16:31 -0300

On Sat, 03 Oct 2009 09:59:39 +0200
Avi Kivity <address@hidden> wrote:

> On 10/01/2009 11:21 PM, Luiz Capitulino wrote:
> >> Regarding info, I think the machine protocol should manage it as
> >> separate commands ("info-cpus" instead of "info"("cpus")).  Having a
> >> function which returns wildly different return types (a string for
> >> version, a device tree for qdev) is unwieldy.
> >>      
> >   I agree and I think this approach would make my life easier.
> >    
> 
> I was thinking more of client writers.

 I see.

> >   The problem though is how to properly refactor the code so that
> > we don't conflict with the user's 'info cpus' command.
> >
> >   I will think about it, but would be good to decide this before
> > mass conversion.
> >    
> 
> One approach would be to have two command tables, one for ordinary 
> commands and one for info commands.  The machine monitor can scan the 
> two tables sequentially, while the human monitor will only scan the 
> first table, and the second as a response to an 'info' command.

 I thought about doing something similar, as we already have a
different table for 'info' commands.

 The disadvantage of this approach though, is that we would have
to handle 'info' handlers differently, ie, we would have to add
special cases in common code.

 Today, a 'info' command is treated as any other command, but
its handler (do_info()) calls the correct handler.

 Not sure if this is a big deal, though.






reply via email to

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