Re: [Qemu-devel] [PATCH v3] ui/cocoa.m: Add Mount image file menu item

[Markus Armbruster]

Programmingkid <address@hidden> writes:

> On Sep 24, 2015, at 2:57 AM, Markus Armbruster wrote:
>
>> Programmingkid <address@hidden> writes:
>> 
>>> On Sep 23, 2015, at 4:35 PM, Peter Maydell wrote:
>>> 
>>>> On 17 September 2015 at 21:17, Programmingkid
>>>> <address@hidden> wrote:
>>>>> Add "Mount Image File..." and a "Eject Image File" menu items to
>>>>> cocoa interface. This patch makes sharing files between the
>>>>> host and the guest user-friendly.
>>>>> 
>>>>> The "Mount Image File..." menu item displays a dialog box having the
>>>>> user pick an image file to use in QEMU. The image file is setup as
>>>>> a USB flash drive. The user can do the equivalent of removing the
>>>>> flash drive by selecting the file in the "Eject Image File" submenu.
>>>>> 
>>>>> Signed-off-by: John Arbuckle <address@hidden>
>>>> 
>>>> I've thought a bit about this, and I really don't think this sort
>>>> of feature should be part of QEMU itself. Our general design for
>>>> how QEMU does this sort of thing is that an external program
>>>> (virt-manager, for instance) is responsible for providing most
>>>> of the UI conveniences the user wants, and QEMU's "ui" code is
>>>> a fairly simple minimum-functionality affair. I agree with Markus
>>>> that this separation of concerns has generally worked OK for us.
>>>> 
>>>> I don't think OSX should be an exception to this design model:
>>>> (a) being an odd special case is never a good idea
>>>> (b) as a practical matter, I'm the only person who really reviews
>>>> OSX patches, and I don't have either the time nor the UI or OSX
>>>> expertise to deal with maintaining what will effectively be a
>>>> vm-manager grafted onto the side of QEMU
>>>> 
>>>> So I think your efforts would be better spent in either porting
>>>> one of the Linux frontends like libvirt/virt-manager, or in
>>>> writing a custom OSX specific frontend.
>>> 
>>> I understand that time is precious. It is one of those things
>>> that we only have a finite amount of. Every user can agree
>>> to that. This patch was pretty hairy looking with the QDict
>>> and other unfamiliar code. With that said I'm not ready to
>>> give up on this patch. It is a huge time saver for the user.
>>> Without it, the user would need to spend a lot of time
>>> investigating documentation. What's worse is the user
>>> would have to type out full paths to files they need. This
>>> would definitely be error prone and frustrating.
>> 
>> Nobody is challenging the idea that many users appreciate a GUI.
>> 
>> What we've been trying to tell you is where in this software layer cake
>> the GUI should be.  In Peter's words, "our general design for how QEMU
>> does this sort of thing is that an external program (virt-manager, for
>> instance) is responsible for providing most of the UI conveniences".
>
> That is easy for you to say. Linux already has virt-manager. Mac OS X 
> doesn't. 
> Expecting someone to just go and port another program to Mac OS X is 
> unreasonable. The amount of time and energy it would take to do so
> would make it hard. 

On the purely technical level, it may or may not be harder than mashing
everything into QEMU.

On the getting-patches-merged level, mashing everything into QEMU is a
non-starter, as Peter and I have told you multiple times.

That tips the balance somewhat.

>>> This patch can definitely be more simplified. QMP
>>> commands could be used in place of C functions. 
>>> This would reduce the patch size greatly. 
>> 
>> You're quite welcome to use QMP the way it wants to be used: as an
>> external interface.
>> 
>> Abusing it as internal interface won't fly.
>
> The QMP interface is primarily there to help a gui interact with QEMU. That
> is what I intend to use it for.

Nope, the QMP interface's purpose is to let other programs interact with
QEMU.

You're free to use it for other purposes to your heart's content.  Just
don't count on patches to be merged when they do things maintainers have
told you not to do :)