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: Thu, 1 Oct 2009 18:21:08 -0300

On Thu, 01 Oct 2009 18:01:20 +0200
Avi Kivity <address@hidden> wrote:

> On 10/01/2009 05:50 PM, Luiz Capitulino wrote:
> >   Hi there,
> >
> >   This series is an updated version of my initial QObject conversion series,
> > which adds the needed infrastructure to incrementally support new style
> > QObject handlers without breaking the current ones.
> >
> >   Some people have suggested that we should have a better error handling
> > in the Monitor, in the meaning that error information should be correctly
> > propagated and handled in order to be used by the Monitor Protocol and
> > the existing user protocol.
> >
> >   This series introduces the MonitorError data type to solve that problem,
> > it's used as part of the new infrastructure.
> >
> >   Additionally the following handlers are converted: do_quit(), do_stop(),
> > do_system_reset(), do_system_powerdown(), do_balloon(), do_info_version(),
> > do_info_balloon().
> >
> >   I've done a full build of QEMU with this series applied on Fedora 11 
> > x86_64
> > and Debian Lenny i386, also tested manually all converted commands plus some
> > easy ones.
> >
> >   Please, review this carefully as some design decisions made here will
> > have impact in the Monitor Protocol.
> >
> >    
> 
> Looks good to me.
> 
> 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.

 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.




reply via email to

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