Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Max Reitz <address@hidden> writes:

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

All good points.

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

No, use the proper internal interface: the C functions implementing the
QMP 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().

Yes, those are two of them.

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

Using handle_hmp_command() as internal interface goes through multiple
layers of formatting and parsing just to call a C function you could've
just as well called directly.

Thus, calling handle_hmp_command() from for any purpose other than
handling QMP command "human-monitor-command" or testing it is
inappropriate.