qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
From: John Snow <jsnow@redhat.com>
To: "Daniel P. Berrangé" <berrange@redhat.com>,
	"Dov Murik" <dovmurik@linux.vnet.ibm.com>
Cc: qemu-devel@nongnu.org, Markus Armbruster <armbru@redhat.com>
Subject: Re: [PATCH] qmp-shell: Suppress banner and prompt when stdin is not a TTY
Date: Wed, 20 Jan 2021 10:46:27 -0500	[thread overview]
Message-ID: <0d56a477-d4dd-ca59-9b16-90ea8c7a1c45@redhat.com> (raw)
In-Reply-To: <20210120094539.GC3015589@redhat.com>

On 1/20/21 4:45 AM, Daniel P. Berrangé wrote:
> On Wed, Jan 20, 2021 at 10:25:25AM +0200, Dov Murik wrote:
>> Hi John,
>>
>> On 19/01/2021 22:02, John Snow wrote:
>>> On 1/17/21 2:27 AM, Dov Murik wrote:
>>>> Detect whether qmp-shell's standard input is not a TTY; in such case,
>>>> assume a non-interactive mode, which suppresses the welcome banner and
>>>> the "(QEMU)" prompt.  This allows for easier consumption of qmp-shell's
>>>> output in scripts.
>>>>
>>>> Example usage before this change:
>>>>
>>>>       $ printf "query-status\nquery-kvm\n" | sudo
>>>> scripts/qmp/qmp-shell qmp-unix-sock
>>>>       Welcome to the QMP low-level shell!
>>>>       Connected to QEMU 5.1.50
>>>>
>>>>       (QEMU) {"return": {"status": "running", "singlestep": false,
>>>> "running": true}}
>>>>       (QEMU) {"return": {"enabled": true, "present": true}}
>>>>       (QEMU)
>>>>
>>>> Example usage after this change:
>>>>
>>>>       $ printf "query-status\nquery-kvm\n" | sudo
>>>> scripts/qmp/qmp-shell qmp-unix-sock
>>>>       {"return": {"status": "running", "singlestep": false,
>>>> "running": true}}
>>>>       {"return": {"enabled": true, "present": true}}
>>>>
>>>> Signed-off-by: Dov Murik <dovmurik@linux.vnet.ibm.com>
>>>
>>> Hiya! I've been taking lead on modernizing a lot of our python
>>> infrastructure, including our QMP library and qmp-shell.
>>>
>>> (Sorry, not in MAINTAINERS yet; but I am in the process of moving these
>>> scripts and tools over to ./python/qemu/qmp.)
>>
>> Thanks for this effort.
>>
>>>
>>> This change makes me nervous, because qmp-shell is not traditionally a
>>> component we've thought of as needing to preserve backwards-compatible
>>> behavior. Using it as a script meant to be consumed in a headless
>>> fashion runs a bit counter to that assumption.
>>>
>>> I'd be less nervous if the syntax of qmp-shell was something that was
>>> well thought-out and rigorously tested, but it's a hodge-podge of
>>> whatever people needed at the moment. I am *very* reluctant to cement
>>> it.
>>
>> Yes, I understand your choice.
>>
>>
>>>
>>> Are you trying to leverage the qmp.py library from bash?
>>
>> Yes, I want to send a few QMP commands and record their output.  If I use
>> socat to the unix-socket I need to serialize the JSON request myself, so
>> using qmp-shell saves me that; also not sure if there's any negotiation done
>> at the beginning by qmp-shell.
> 
> There is a handshake, but it is just a single json message.
> 
> See docs/interop/qmp-intro.txt and qmp-spec.txt for guidance.
> 
>> Is there an easier way to script qmp commands, short of writing my own
>> python program which uses the qmp.py library?
> 
> Yes, writing your own python program is probably best. Doing anything
> complex is shell is almost always a mistake, as it is a very crude
> and poor language compared to something like managing QEMU/QMP.
> 
> Note that I don't believe that we've declared qmp.py to be a long
> term stable interface for users outside of QEMU either. An alternative
> is to just use the python sockets APIs directly to speak to QEMU/QMP
> 

Right. qmp.py is technically not stable either, but it at least doesn't 
use an invented syntax we don't have a spec for ... and it is used by 
quite a few other things in the tree, so I trust it /slightly/ more. I 
cannot promise compatibility for scripts that aren't in the tree at this 
time, though.

(I am working on an asyncio variant of the QMP library that I do hope to 
promise stability for, but that's probably not something you can hope to 
see in the short term. It will likely have an API that is at least 
somewhat similar to the existing library, but will use asyncio 
coroutines instead of blocking calls.)

You can look at ./tests/qemu-iotests/ for some examples of using the QMP 
library that we have today; grep for '.qmp(' to find examples.

The connection for these tests is established in python/qemu/machine.py, 
look at the 'self._qmp_connection' field. This connection is exposed via 
the qmp(...) method, which the tests use. The library handles the (very 
small) handshake.

There are also bash tests in ./tests/qemu-iotests/ that handle some QMP 
by themselves, and might be up your alley for very simple cases. Test 
060 sets up its own QMP connection and just echoes JSON into the pipe.

--js



  reply	other threads:[~2021-01-20 15:49 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2021-01-17  7:27 [PATCH] qmp-shell: Suppress banner and prompt when stdin is not a TTY Dov Murik
2021-01-19 20:02 ` John Snow
2021-01-20  8:25   ` Dov Murik
2021-01-20  9:45     ` Daniel P. Berrangé
2021-01-20 15:46       ` John Snow [this message]
2021-01-20 18:10         ` Dov Murik

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=0d56a477-d4dd-ca59-9b16-90ea8c7a1c45@redhat.com \
    --to=jsnow@redhat.com \
    --cc=armbru@redhat.com \
    --cc=berrange@redhat.com \
    --cc=dovmurik@linux.vnet.ibm.com \
    --cc=qemu-devel@nongnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).