On Mon, 01 Mar 2010 08:59:38 +0100 Markus Armbruster <arm...@redhat.com> wrote:
> Luiz Capitulino <lcapitul...@redhat.com> 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.
