From: Max Reitz <mreitz@redhat.com>
To: Programmingkid <programmingkidx@gmail.com>
Cc: Peter Maydell <peter.maydell@linaro.org>,
qemu-devel qemu-devel <qemu-devel@nongnu.org>
Subject: Re: [Qemu-devel] Mount image file feature
Date: Wed, 2 Sep 2015 16:31:24 +0200 [thread overview]
Message-ID: <55E7083C.4060301@redhat.com> (raw)
In-Reply-To: <63FAA579-CD4E-455C-BE7D-30B79A8F7174@gmail.com>
[-- Attachment #1: Type: text/plain, Size: 2942 bytes --]
On 31.08.2015 22:33, Programmingkid wrote:
>
> On Aug 31, 2015, at 4:26 PM, Max Reitz wrote:
[snip]
>> The following works for me:
>>
>> $ echo foo > bar
>> $ x86_64-softmmu/qemu-system-x86_64 -qmp stdio -usb -cdrom
>> ~/tmp/archlinux-2015.07.01-dual.iso -enable-kvm -m 512
>> {"QMP": {"version": {"qemu": {"micro": 50, "minor": 4, "major": 2},
>> "package": ""}, "capabilities": []}}
>> {'execute': 'qmp_capabilities'}
>> {"return": {}}
>> {'execute': 'blockdev-add', 'arguments': {'options': {'id': 'usb-image',
>> 'driver': 'raw', 'file': {'driver': 'file', 'filename': 'bar'}}}}
>>
>> {"return": {}}
>> {'execute': 'device_add', 'arguments': {'driver': 'usb-storage', 'id':
>> 'usb-disk', 'drive': 'usb-image'}}
>> {"return": {}}
>>
>> In the VM, before device_add:
>> # cat /dev/sda
>> cat: /dev/sda: No such file or directory
>>
>> After device_add:
>> # cat /dev/sda
>> foo
>
> Is there a function that the GUI could call to send all of the JSON code as the
> argument to execute.
If you put the GUI outside of qemu, it's very simple, obviously, since
you then just need to send it to whichever interface you chose to be
used for QMP.
(Yes, I'm still strongly encouraging you to write a separate GUI. The
only part that I suppose to be more difficult than when putting
everything into qemu itself is integrating the guest output into your
GUI. Ideally you'd probably either use VNC or qxl/spice for that, but
for the start I personally would just use SDL (it does work on OS X,
too, doesn't it?) so you get a bare window which is only the guest
output, and then put the VM controls into a separate window.)
The nice thing about a GUI outside of qemu, besides looking preferable
design-wise to me, is that you can configure the VM offline, too.
For the GUI inside of qemu: Well, there is handle_qmp_command(), but it
doesn't look like it's intended to be used directly. Judging from
monitor.c, you'd want to set up a JSON parser, call
json_message_parser_init(parser, handle_hmp_command); and then use
json_message_parser_feed() to send commands.
So the GUI inside of qemu would probably want to continue to call qmp_*
directly, i.e. qmp_blockdev_add() and qmp_device_add().
>> Unplugging the device can be done with device_del; but there is no
>> blockdev-del yet, so the image file will remain lingering.
>
> If the user decided to use the same image file again, would that be possible?
Yes, but you'd have to keep track of the ID you gave it. If you call
blockdev-add again, qemu will happily open it anew and then it'll be
open twice.
> What about handle_hmp_command() in monitor.c. Would it be ok to
> send commands to execute?
Depends on you definition of "ok". As long as it works, well, it'll
work. But HMP is intended for human use, that's where the H comes from.
It's also not as powerful as QMP, e.g. there's not blockdev-add.
Max
[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 473 bytes --]
next prev parent reply other threads:[~2015-09-02 14:31 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-27 1:05 [Qemu-devel] Mount image file feature G 3
2015-08-29 15:40 ` Max Reitz
2015-08-29 15:57 ` Programmingkid
2015-08-29 16:39 ` Max Reitz
2015-08-29 17:36 ` Programmingkid
2015-08-29 18:01 ` Max Reitz
2015-08-29 18:34 ` MagicCat Software
2015-08-29 19:34 ` Max Reitz
2015-08-29 20:06 ` Programmingkid
2015-08-29 23:10 ` Eric Blake
2015-08-30 0:02 ` Programmingkid
2015-08-30 7:15 ` Paolo Bonzini
2015-08-29 19:52 ` Max Reitz
2015-08-29 20:18 ` Programmingkid
2015-08-29 23:12 ` Eric Blake
2015-08-29 23:31 ` Programmingkid
2015-08-29 23:04 ` Eric Blake
2015-08-30 0:03 ` MagicCat Software
2015-08-31 8:02 ` Markus Armbruster
2015-08-30 6:47 ` Paolo Bonzini
2015-08-31 3:47 ` Programmingkid
2015-08-31 7:52 ` Markus Armbruster
2015-08-31 13:12 ` Programmingkid
2015-08-31 16:26 ` Markus Armbruster
2015-08-31 18:29 ` Programmingkid
2015-08-30 6:42 ` Paolo Bonzini
2015-08-31 20:13 ` Programmingkid
2015-08-31 20:26 ` Max Reitz
2015-08-31 20:33 ` Programmingkid
2015-09-02 14:31 ` Max Reitz [this message]
2015-09-02 14:38 ` Programmingkid
2015-09-03 9:46 ` Markus Armbruster
2015-09-03 14:24 ` Programmingkid
2015-09-03 16:26 ` Markus Armbruster
2015-09-03 16:51 ` Programmingkid
2015-09-03 9:34 ` Markus Armbruster
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=55E7083C.4060301@redhat.com \
--to=mreitz@redhat.com \
--cc=peter.maydell@linaro.org \
--cc=programmingkidx@gmail.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).