On Sep 3, 2015, at 5:46 AM, Markus Armbruster wrote:
> Programmingkid <programmingk...@gmail.com> writes:
>
>> On Sep 2, 2015, at 10:31 AM, Max Reitz wrote:
>>
>>> 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?)
>>
>> Yes it does.
>>
>>> 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.
>>
>> Wow, that is a bit overwhelming. I really like what my patch does. It
>> just sends a
>> command to the monitor as if the user typed it up. Very simple, easy,
>> and effective.
>> I will never have to look for some poorly documented function again!
>
> On the flip side, you'll never get a patch abusing handle_hmp_command()
> or handle_qmp_command() as internal interface committed.
>
>>> 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.
>>
>> I just call drive_del then device_del. So far so good. I have mounted
>> and unmounted the same image file several times without problem.
>
> Wrong order, trap for the unwary. Let me paste my standard advice:
>
> drive_del is nasty. Its purpose is to revoke access to an image
> even when the guest refuses to cooperate. To the guest, this looks
> like hardware failure.
Has the device been probably ejected from the guest first?
>
> If you drive_del before device_del, even a perfectly well-behaved
> guest guest is exposed to a terminally broken device between
> drive_del and completion of unplug.
>
> Always try a device_del first, and only if that does not complete
> within reasonable time, and you absolutely must revoke access to the
> image, then whack it over the head with drive_del.
I guess I could use "device_del" only. I just thought it made sense to use
"drive_del" when I used the "drive_add" command.
>
> Copied from
> http://lists.gnu.org/archive/html/qemu-devel/2014-04/msg00116.html
>
> I hope we can eventually replace and deprecate drive_del with something
> that where the obvious use is the correct one.
I haven't noticed any problems so far. When I use "drive_del", the "info block"
command says it is gone. That is good. Then I do a "device_del". "info usb"
shows
the device gone. Maybe any problems with "drive_del" you might have had in the
past have been fixed. Have you tried it out lately? I did extensive testing of
my patch
using Debian Linux as a guest. Never heard it complain.
