From: Kashyap Chamarthy <kchamart@redhat.com>
To: John Snow <jsnow@redhat.com>
Cc: Stefan Hajnoczi <stefanha@gmail.com>,
Eduardo Habkost <ehabkost@redhat.com>,
Markus Armbruster <armbru@redhat.com>,
Stefan Hajnoczi <stefanha@redhat.com>,
QEMU Developers <qemu-devel@nongnu.org>
Subject: Re: Call for Google Summer of Code 2021 project ideas
Date: Fri, 15 Jan 2021 17:31:10 +0100 [thread overview]
Message-ID: <20210115163110.GB94798@paraplu.home> (raw)
In-Reply-To: <c26786ac-159e-149a-aa5e-dd08f418d11e@redhat.com>
On Thu, Jan 14, 2021 at 11:36:23AM -0500, John Snow wrote:
> On 1/14/21 7:29 AM, Markus Armbruster wrote:
[...]
> So I see two possible options for "not inventing a language":
>
> 1. Raw QMP
> 2. The existing qmp-shell syntax, warts and all.
>
> I don't see a tremendous problem with doing both; but we can start with raw
> QMP. The existing qmp-shell syntax is at least definitely very easy to write
> a new parser for, even if it's kind of ugly and insufficient. I still see
> value in designing a new TUI with the old syntax.
>
> > The project then aims to build a tool that adds useful features over
> > "socat "READLINE,history=$HOME/.qmp_history,prompt=QMP>"
> > UNIX-CONNECT:/path/to/socket".
> >
> > If it succeeds, you can still design and implement a "better" language,
> > and let users choose the one they prefer. Or you could add features to
> > help with typing QMP.
> >
> > > I don't
> > > think it's a blocker to have someone work on the TUI and asynchronous
> > > dispatch elements. I think even just keeping our current parsing but
> > > adding some of the features outlined in the proposal would be a big
> > > usability win.
> >
> > I don't feel this particular itch, but I'm certainly not objecting to
> > anyone scratching.
> >
>
> It's something I'd like to see so that I can walk non-QEMU devs through
> interacting with QEMU at a low level for the purposes of debugging,
> reproducing problems, prototyping features, etc.
>
> I use qmp-shell all the time for debugging things myself, I find it easier
> to use than copy-pasting things directly into socat. I wouldn't mind the
> shell getting a little smarter to help me out -- the ability to see async
> events and reconnect on disconnect would already be a massive improvement to
> *my* quality of life.
As an infrequent user of `qmp-shell`, the async events stuff is really
beneficial to me too. And, I'm happy to play the test guinea pig to
give the patchs a spin. (I'm somewhat behind on the goings-on in this
area, very slowly catching up.)
> So much so that I spent a lot of time in December to write an async qmp
> library O:-)
Nice, I recall that you planned to use the 'asyncio' primitives from
Python 3.6.
--
/kashyap
next prev parent reply other threads:[~2021-01-15 16:41 UTC|newest]
Thread overview: 27+ messages / expand[flat|nested] mbox.gz Atom feed top
2021-01-11 11:47 Call for Google Summer of Code 2021 project ideas Stefan Hajnoczi
2021-01-12 21:10 ` John Snow
2021-01-13 8:53 ` Stefan Hajnoczi
2021-01-13 18:59 ` qmp-shell TUI (was: Re: Call for Google Summer of Code 2021 project ideas) John Snow
2021-01-14 13:52 ` Stefan Hajnoczi
2021-01-14 13:59 ` Daniel P. Berrangé
2021-01-14 15:02 ` Kevin Wolf
2021-01-14 15:22 ` Daniel P. Berrangé
2021-01-14 16:49 ` Stefan Hajnoczi
2021-01-14 16:55 ` Daniel P. Berrangé
2021-01-14 17:14 ` Stefan Hajnoczi
2021-01-14 17:24 ` Daniel P. Berrangé
2021-01-14 16:48 ` Stefan Hajnoczi
2021-01-14 17:48 ` John Snow
2021-01-13 9:19 ` Call for Google Summer of Code 2021 project ideas Markus Armbruster
2021-01-13 19:05 ` John Snow
2021-01-14 12:29 ` Markus Armbruster
2021-01-14 14:57 ` Kevin Wolf
2021-01-14 16:36 ` John Snow
2021-01-15 16:31 ` Kashyap Chamarthy [this message]
2021-02-15 11:05 ` Paolo Bonzini
2021-02-15 21:47 ` John Snow
2021-02-12 13:22 ` [Rust-VMM] " Florescu, Andreea
2021-02-12 13:51 ` Sergio Lopez
2021-02-17 11:20 ` Stefan Hajnoczi
2021-02-18 11:49 ` Andreea Florescu
2021-02-18 17:43 ` Stefan Hajnoczi
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=20210115163110.GB94798@paraplu.home \
--to=kchamart@redhat.com \
--cc=armbru@redhat.com \
--cc=ehabkost@redhat.com \
--cc=jsnow@redhat.com \
--cc=qemu-devel@nongnu.org \
--cc=stefanha@gmail.com \
--cc=stefanha@redhat.com \
/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).