Re: [Qemu-devel] [PATCH RFC 00/48] Convert device_add to QObject / QError

[Luiz Capitulino]

On Mon, 01 Mar 2010 08:59:38 +0100
Markus Armbruster <address@hidden> wrote:

> Luiz Capitulino <address@hidden> writes:

[...]

> >                                We didn't expose 'info', for example, because
> > having a command (or 'remote procedure') returning all sorts of possible
> > data is no good.
> 
> Why?  What's the fundamental difference between having to enumerate all
> the possible arguments of "info" and their replies, and having to
> enumerate all the possible FOOs valid with "query-FOO", and their
> replies?

 It's not about enumeration, it's about design.

 All 'info' commands are actually individual functions that are exposed in
the user Monitor as 'info foo' commands for _user_ convenience: we group
them together under the 'info' namespace. Less commands into the 'global'
namespace, easier to get a listing and so on. Also, all the user sees is
text related to the command typed, so it makes sense.

 Now, these arguments don't apply for a machine protocol. Here, what's
important is a clear and consistent command set. User's 'info' command
is neither from a low-level POV, as it returns too much unrelated data.

> For what it's worth, "info" returns much richer data than device_add.

 Yes, but the problem here is input.

 On the other hand, as I said somewhere else, this is somewhat beyond
the protocol design decisions because device_add is the direction qemu
is taking wrt its device model.

> >  Two questions:
> >
> > 1. Don't we need a 'query-devices' command?
> 
> There's "info qdm".  It doesn't show properties, but it could.  Its
> output is already plenty long, so for humans we better provide a way to
> ask for a single driver's properties.

 Ok.

> There's also "device_add ?" and "device_add DRIVER,?", but that's for
> humans.  For QMP, we want to keep queries and actions neatly separate.

 Yes.

> > 2. How are we going to document all the accepted parameters? Note
> >    that as we're exposing them through QMP, they obviusly must not change
> >    (although this probably a requirement for the CLI as well)
> 
> We want command self-documentation to enumerate all accepted parameters.
> For device_add, I'd make it say "accepts any".  That's a lie, as it
> really accepts only device properties.  Thus, Clients can't learn device
> properties from the device_add command, they need to query the device
> model.  I'm fine with that.

 Yes.