From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:42852) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX94X-0000GR-Ie for qemu-devel@nongnu.org; Wed, 02 Sep 2015 10:31:34 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZX94T-0001yB-1S for qemu-devel@nongnu.org; Wed, 02 Sep 2015 10:31:33 -0400 Received: from mx1.redhat.com ([209.132.183.28]:34320) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZX94S-0001xq-QE for qemu-devel@nongnu.org; Wed, 02 Sep 2015 10:31:28 -0400 References: <55E1D289.9000202@redhat.com> <55E1E03A.6060002@redhat.com> <89185148-279E-402F-8AC2-76FA97A1FD43@gmail.com> <55E4B86E.6090007@redhat.com> <63FAA579-CD4E-455C-BE7D-30B79A8F7174@gmail.com> From: Max Reitz Message-ID: <55E7083C.4060301@redhat.com> Date: Wed, 2 Sep 2015 16:31:24 +0200 MIME-Version: 1.0 In-Reply-To: <63FAA579-CD4E-455C-BE7D-30B79A8F7174@gmail.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="Kjr9OA9UvT9RgFAQI7Hexqm0i0obfm5v8" Subject: Re: [Qemu-devel] Mount image file feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Peter Maydell , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --Kjr9OA9UvT9RgFAQI7Hexqm0i0obfm5v8 Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 31.08.2015 22:33, Programmingkid wrote: >=20 > 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 >=20 > Is there a function that the GUI could call to send all of the JSON cod= e 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. >=20 > If the user decided to use the same image file again, would that be pos= sible? 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 --Kjr9OA9UvT9RgFAQI7Hexqm0i0obfm5v8 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV5wg8AAoJEDuxQgLoOKyt238H/jo5H0awOajJvxkLkyzqFhhD hrl0uOca4mIu6ytEtkumupXA4UK18DtPVNitQQGHuMaT3hyX/6X5FXdE6rwXXrK+ AzkXNagTv1eZZoCKobkGA1Sdl8Wjl7A49uMvdOsUYA3+zGdJrLP11f1l7XIUFQMc 0st4ODQzqkxJl8sMN7dUrI3xFVvSQZ0JtwfgZTnuOpFmw4XX+Mgu8HB9cWy2UmnA 8rbpDTpWxgvA5mcMqAyUwf5fzdhfhj6da5CeVZs+VqII7P16Xy3TPwdjzGTf7M7r 81OtfZtZCFdMOE/tJMfSsCHoGk5ZhhBtGA6zDurl1gzwDHLj+TWzmyuU8cgoTq4= =pvmG -----END PGP SIGNATURE----- --Kjr9OA9UvT9RgFAQI7Hexqm0i0obfm5v8--