qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-devel] Mount image file feature


From: Markus Armbruster
Subject: Re: [Qemu-devel] Mount image file feature
Date: Mon, 31 Aug 2015 18:26:31 +0200
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (gnu/linux)

Programmingkid <address@hidden> writes:

> On Aug 31, 2015, at 3:52 AM, Markus Armbruster wrote:
>
>> 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.
>
> I think the word attack is a little strong. We were just having a
> little informal
> conversation.

We're having a technical argument.  Such arguments can occasionally get
a little heated, but that's fine, we don't mean each other harm :)

>               Sorry if the Linux jokes weren't so funny.

No offense taken.

>>  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.
>
> That's what you believe? Are you saying if we do add a few features to the GUI
> it automatically becomes bad? Isn't that kind of pessimistic? Is all hope 
> gone?

I think we QEMU developers have our hands full with our core mission,
and saddling ourselves with GUI development on top risks failure.

You're welcome to prove me wrong.

> Running Virt-manager on Mac OS X isn't currently possible. So my only
> choice is to advance
> the GUI.

Very rarely something is your only choice.

You could work on libvirt and virt-manager under Mac OS X.  A quick grep
shows #ifdef __APPLE__ in libvirt sources, which suggests it already
runs there.

You could write your own GUI layered on top of QEMU.

>          This feature would making transferring files from and to the
> guest actually easy
> to do. That sounds like a good idea.

Plumbing for easy file sharing is part of our core job.  I think Max
pointed you to the work being done by Stefan (NFS over AF_VSOCK).  A
less capable, but more portable alternative could be USB MTP.

>                                      This patch would only affect Mac
> OS X users, so Linux
> users won't notice a difference. No harm done to them.

There's always the opportunity cost.



reply via email to

[Prev in Thread] Current Thread [Next in Thread]