qemu-devel.nongnu.org archive mirror
 help / color / mirror / Atom feed
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



  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).