Re: [Qemu-devel] Mount image file feature

[Markus Armbruster]

Programmingkid <address@hidden> writes:

> On Aug 29, 2015, at 12:39 PM, Max Reitz wrote:
>
>> On 29.08.2015 17:57, Programmingkid wrote:
>>> 
>>> On Aug 29, 2015, at 11:40 AM, Max Reitz wrote:
>>> 
>>>> On 27.08.2015 03:05, G 3 wrote:
>>>>> I want to share files between my host and guest computer. A feature I
>>>>> want to add would be a new menu item in the Machine menu called "Mount
>>>>> Image File...". When the user selects it, a file open dialog box
>>>>> displays. The user can then select the image file with the file he wants
>>>>> to use. After pushing the OK button, the image file would be mounted
>>>>> like a USB flash drive. This menu item would only show up if there is
>>>>> usb support in the guest machine.
>>>>> 
>>>>> Would you be open to accepting such a feature?
>>>> 
>>>> Generally I'd expect this to be functionality exposed by the management
>>>> layer. For instance using virt-manager, this can be achived as follows:
>>>> Switch to "Details", then click "Add Hardware", choose "Storage" and
>>>> "USB" as the "Bus type". Choose the image, click "Finish", done.
>>> 
>>> Isn't Libvirt only available on Linux? This mount image file feature would
>>> only be on Mac OS X.
>> 
>> I'm not sure whether that sounds like a good idea, because then people
>> using bare qemu on Linux would complain that it isn't available with
>> Gtk. So if this was to be implemented, it would have to implemented
>> cross-platform (or at least in a way so it can be used cross-platform
>> later on).
>
> If making QEMU more user-friendly is a crime, I plead guilty!
>
> I'm not a Linux user. I am a proud Macintosh user. We Mac users
> like our software easy to use. I know this goes against the Linux
> way of life. That is why this patch would only work on Mac OS X. 
> This will keep QEMU on Linux hard to use... just the way you guys
> like it.

I think you've used up your "speculation on what Linux users like" quota
on this list for 2015.  Now let's get back on topic.

[More snipped...]

>>>> The main problem I see with adding this functionality to qemu itself
>>>> would be having to get even further into the GUI business, which hasn't
>>>> worked out too well so far…
>>> 
>>> That is because of several reasons. One being maintainers not wanting to
>>> advance the GUI because they feel another program should be QEMU's 
>>> GUI. I'm sure there are plenty of good ideas that would advance QEMU's
>>> GUI. These ideas just need to be accepted into QEMU rather than put off.
>> 
>> Another is that some people simply feel that qemu should focus on being
>> a backend than having to mess with frontend work, too. See the recent
>> discussion on the Gtk code setting the locale and thus breaking QMP for
>> an example why they have a point.
>
> We can have both. Command-line options are there that can turn on or
> off the GUI.
> Example: --disable-gtk.
>
> Ideally I want QEMU's GUI to be similar to VirtualBox's GUI. Doing stuff like
> freezing and restoring a session would be awesome and a real time saver.
>
>> I guess you'll better talk to Markus about this. :-)
>> 
>> Quote: "We should've stayed out of the GUI business."
>> 
>> (http://lists.nongnu.org/archive/html/qemu-devel/2015-08/msg03049.html)
>
> That is totally fine for the Linux users. If they want to use the
> command-line only,
> let them. They are only hurting themselves :)

You're attacking a strawman.  Nobody is arguing against having a nice
GUI.  My argument is that one application trying to do everything tends
to result in the application doing most of it badly.

Case in point: QEMU tries to be the low-level user space plumbing for
virtualization, and machine emulation, and GUI.  Even just the first two
create tension by having different requirements, but at least they take
quite similar kinds of expertise.  GUI is a quite different business.

I think we should focus on what really, really needs to be done in QEMU.
GUI can and should be layered on top.

I'm not going to oppose improvements to the built-in GUI just because of
my opinion on the wisdom of having a built-in GUI.  I am, however, quite
critical of such efforts distracting us from our core job.

Patches to improve the GUI that don't touch non-GUI code: hash it out
with the relevant maintainer.  Balancing distraction against utility is
his job, not mine.

Non-GUI patches you want for GUI work that can stand on their own as
contributions to our core job: sounds useful, thanks!

Non-GUI patches that don't contribute to our core job: rejecting small
and simple ones is probably more distraction than taking them, but I'd
advise against big ones.  The relevant maintainers may have different
opinions, of course, and they decide.


[...]