On 2/9/21 8:57 AM, Niteesh G. S. wrote:
> Hello John,
> On Mon, Feb 8, 2021 at 8:44 PM John Snow <jsnow@redhat.com
> <mailto:jsnow@redhat.com>> wrote:
> On 2/7/21 12:01 PM, Niteesh G. S. wrote:
[...]
>
>
> Which one in your opinion will yield a faster response, Mailing list or IRC?
> My problem with IRC is, I don't have an IRC bouncer set up so I miss
> some conversations. Which one is simpler to use? There are many options
> available. Is there something that will not require me to host a server?
>
Indeed one of the problems with IRC :)
IRC can be faster if you happen to join at the right time, when people
are around and paying attention. We generally conduct interviews and
meetings for GSoC/Outreachy at scheduled times on IRC.
If you don't get an answer fairly quickly on IRC, send a mail. If you'd
like to chat more interactively than mail allows, try and ask for an
explicit time for someone to meet with you on IRC.
OK.
> See the end of this mail for instructions on how to join, if you
> need them.
>
> I am already part of the QEMU IRC channel. But thanks for these
> instructions.
>
Sorry, I wasn't sure! I try to be aware that IRC is increasingly a thing
that only weird old coots use :p
[...]
>
>
> Thank you so much for the detailed answer. This helped a lot.
> After reading the docs and messing around with simple commands.
> I am confused about few things.
>
> 1) What is the difference between QMPShell and HMPShell? My understanding
> after going through code and doco is both talk to QEMU using QMP and
> basically
> do the same thing but HMPShell is a subset of QMP shell which is
> more human-friendly
> compared to QMPShell. Is that right?
>
"It's complicated ..."
HMP shell is an older protocol that QEMU has that is meant to be more
human-friendly, yes. Many of its commands are implemented in terms of
QMP commands, but not all of them. It isn't right to call it a "subset".
QMP was introduced to create an API that was more machine-friendly than
HMP, but we didn't finish porting everything from HMP to QMP, for a few
reasons.
(1) HMP does not have any backwards compatibility promises; this makes
it more appealing for various debugging commands and alpha/beta versions
of commands. QMP is meant to have fairly strict backwards compatibility
and a reliable API.
(2) QMP is designed as a control channel and not a data transfer
channel, so some commands that may transmit large amounts of data or
take indeterminate amounts of time have remained stuck in HMP without a
proper QMP equivalent.
Naturally, you can use QMP to issue HMP-only commands if you want. There
are a few uses of this in ./tests/qemu-iotests to do various "unsafe"
things.
Daniel Berrange is working on porting "savevm" from HMP to QMP as one of
our last holdouts that isn't just debugging/query stuff.
Whether or not we want to sunset HMP long-term is, AFAIK, an unresolved
question. There are obvious uses for a user-friendly shell. Part of the
qmp-shell revamp project is to investigate the viability of a
user-friendly shell backed only by QMP, where the "friendly" bits are
outside of QEMU proper and not subject to backwards compatibility promises.
> 2) When I press <CTRL-A> - C in QEMU I get a monitor prompt, after
> reading the man page I go to know that I can use telnet or socat to control
> as well. Is this another interface to QEMU which uses QMP?
>
I'm not sure I know what this keypress does! If you see a prompt,
though, it's HMP. Type "help" and send a newline.
The QMP protocol is described somewhere in /docs/ like I pointed out in
my reply. You should get a greeting and you should be able to post a qmp
capabilities handshake and get a reply.
Thank you for the explanation.
> 4) Understanding my project
>
> If you're still interested in my project, I'd recommend trying out
> qmp-shell against a running QEMU instance and issuing a few basic,
> boring commands ("query-status" is a good candidate) and seeing how
> that
> works.
>
> Then, I'd take a look at some of the other projects I mentioned
> (mitmproxy, irssi) to get a sense of what the work is here. This is
> largely a UI/API programming task, and there's real work to do on the
> AQMP library, but it's probably closer to the surface than the deep
> technical internals of QEMU.
>
> It might be a good introductory project that helps you get a better
> overview of the internals of QEMU if you're interested in more
> hardware-related aspects, but it still requires you have at least some
> interested in UI programming and API design.
>
> Phil's project might involve hardware specifics quite a bit more than
> mine, while still teaching you some overview of QMP as a necessity of
> the project.
>
> TBH UI and Async are both quite new to me, I have only done CLI
> stuff since there isn't much UI in low-level dev. I also wanted to try
> out async
> dev at a serious scale but never got an opportunity to do so. My rationale
> behind choosing Phil's project is it would let me learn about the hardware
> emulation and more importantly the visualization stuff using QEMU. But since
> your project involves also async stuff I would love to work on your
> project if
> you allow me to ;).
>
Yup, understood.
> If you remain interested after the above, I can point you towards some
> more concrete tasks that need doing for you to get a fairly concrete
> sense of what the project entails.
>
> Please, If you have any small tasks pending, I would like to work on them.
>
OK: I think I need to be careful about "issuing" work to someone who
isn't (yet) accepted into the program -- I shouldn't misrepresent this
arrangement -- but I can give you some more research tips that may help
you find your footing.
We can work on getting to know QMP a bit better; it sounds like it'd be
relevant for both projects.
Try using '-qmp qmp.sock,server,nowait' when you boot up QEMU and then
open the qmp.sock file with socat and try messing with it.
Try going to ./qapi/ in the source tree and "git grep event" to find
some event definitions. try grepping for that event name in the QEMU
tree at large and try to work out how QEMU emits these events.
Try *adding* an event somewhere in ./qapi/ and modifying QEMU to emit
this event. Try using rlwrap and socat to connect to this QMP socket and
verify that your event is being sent over the wire. Depending on where
you add the event, it may be helpful to start QEMU in a paused state and
issue a resume command from QMP to make sure you have time to connect to
the socket.
I added an event that is emitted every keypress. It also sends the qcode of the key pressed.
After doing this, I think I have a basic understanding of how the event stuff works and also
what happens when a command is issued from the shell.
I have summarized my understanding below, please correct me if I am wrong anywhere.
1) The JSON files under qemu/qapi define the QMP messages. These JSON files are then
compiled into their C representations during the build time.
2) These are then registered using qmp_register_command.
3) When a QMP request is initiated, the commands respective C function is found from the
registered list of commands and is dispatched. One of the main functions responsible for the
finding and dispatching of qmp_* functions is qmp_dispatch in qapi/qmp-dispatch.c. Which
is invoked from monitor/qmp.c upon a QMP request. The result is then published to the user
through monitor_qmp_respond -> qmp_send_response.
Similar stuff happens to events too, the difference being, the function definitions are autogenerated
depending on their schema, whereas for commands only the function prototypes are generated.
The events can be emitted through qapi_event_send_EVENT_NAME functions. These functions
convert C to JSON and call qapi_event_emit which then finally calls the monitor function to display an
event to the user.
Few things I couldn't figure out and understand are
1) Who informs the monitor that the command is been issued? Since there are many ways to
connect to the monitor, I think there should be a generic API which informs about input data.
But I can't find the code behind all this.
Before sending this mail, I decided to give this another try and found
qemu_chr_fe_set_handlers is responsible for register the handlers for input and output. Is that
right? And also does chr_fe mean character_front_end?
2) I couldn't understand QEMU co-routines in general. In this case, I couldn't understand the
coroutine code in qmp_dispatch in qapi/qmp-dispatch.c. Also please explain OOB in simple
terms? How are they different from normal commands? And also their relation with coroutines.
Thanks,
Niteesh.
For more hardware-oriented avenues of exploration, I'd encourage
reaching out to phil, who seems to have a knack for finding weird
embedded devices to babysit :)
>
> > I would like to work on these projects even outside of GSoC if
> someone
> > is ready to
> > mentor in their free time :).
> >
>
> Thanks,
> Niteesh.
>
> Feel free to join #qemu-gsoc on irc.oftc.net <http://irc.oftc.net>.
> If you've not joined an
> IRC channel before, it's kind of like a prehistoric slack channel.
>
> Linux GUI: xchat, hexchat
> Linux TUI: irssi, WeeChat
>
> OSX GUI: LimeChat, Colloquy (I've never used either)
> OSX TUI: irssi and weechat should be available via ports (Not tried.)
>
> Windows GUI: mIRC, XChat
>
>
> I'm jsnow on OFTC. You can use my nickname at the start of a message
> ("jsnow: Hello, this is Niteesh from the mailing list") and it will
> show
> me a notification -- but the hours I am paying attention to IRC are
> around 10AM - 7PM EST. (15:00 - 00:00 GMT)
>
> I can be around later by request (00:00 - 05:00 GMT) if you give me
> some
> advance notice.
>
> > Thanks
> > Niteesh.
> >
> >
>