Re: [Qemu-devel] [PATCH] input: improve docs for input-send-event qmp command

[Eric Blake]

On 11/24/2014 08:51 AM, Markus Armbruster wrote:
> Uh, you dropped cc: Eric somehow a couple of messages ago.

At least I have my inbox set to flag messages where my name is
mentioned, even when I'm not actually cc'd, so I did see the thread
before this email :)


>> Supporting device (additionally to or instead of console) on qmp
>> certainly is an option.  IIRC that was briefly discussed, then we've
>> figured console number is simpler and in most cases not relevant anyway
>> (typical config doesn't has multiple input devices), and if you really
>> need it there are the qom properties to go figure.
>>
>>> As long as we have both, documentation needs to stitch them together.
>>> Your explanation is a start, but it needs to be in a patch, not just in
>>> a mailing list archive :)
>>
>> Sure.  Question is where to stick it best.
> 
> I guess docs/multiseat.txt is the only place where we can explain the
> connection in sufficient detail, and have the right context.
> 
> My gut feeling is to treat console numbers as an implementation detail,
> and go with qdev IDs exclusively.  Could be simpler than documenting
> console numbers :-}

That seems reasonable, but then we do run into the timing issue.

> 
> However, we're running out of time: rc3 is scheduled for tomorrow.  Two
> ways to avoid tying our hands prematurely:
> 
> * Radical: disable the command for the release, bring it back
>   afterwards.  No compatibility worries whatsoever.

The command is brand new, so ripping it out to avoid baking in a mistake
and then adding it for 2.3 does indeed give us more time to get it right.

> 
> * Surgical: rip out optional parameter console for the release, bring it
>   or a replacement back afterwards.  Workable, because we can add
>   optional parameters to existing commands.  However, management tools
>   might want to figure out whther the optional parameter is accepted,
>   and that's not easy since we still can't introspect.

That does become a bit more difficult.  Hey, what happens if I do:

{"execute":"input-send-event",
 "arguments":{"console":0, "events": [] } }

that is, send a 0-length array of events to console 0?  (Or whatever
name we pick instead of 'console' when adding in an optional argument
for 2.3).  If the resulting error message in 2.2 (when the optional
argument is NOT supported) is obvious, and the code in 2.3 (when the
support is added) either silently does nothing with success, or gives a
distinct error message to 2.2, then that serves as something that
management can probe.  But it is a bit more awkward than the first
proposal of just completely delaying the interface until 2.3.

Of course, if we think we can resolve the interface questions and get a
stable interface into 2.2 where we aren't baking in a mistake, then go
for it.  But I don't think this patch is quite there yet, and we're
running low on time for a v2.

-- 
Eric Blake   eblake redhat com    +1-919-301-3266
Libvirt virtualization library http://libvirt.org

signature.asc
Description: OpenPGP digital signature