From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:45089) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVjAA-00034B-0g for qemu-devel@nongnu.org; Sat, 29 Aug 2015 12:39:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZVjA6-0003mx-QM for qemu-devel@nongnu.org; Sat, 29 Aug 2015 12:39:29 -0400 Received: from mx1.redhat.com ([209.132.183.28]:53515) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZVjA6-0003l4-HY for qemu-devel@nongnu.org; Sat, 29 Aug 2015 12:39:26 -0400 References: <55E1D289.9000202@redhat.com> From: Max Reitz Message-ID: <55E1E03A.6060002@redhat.com> Date: Sat, 29 Aug 2015 18:39:22 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="SGpU5TrHaFjsmAS8rJMNIxf7hJHoAaSmi" Subject: Re: [Qemu-devel] Mount image file feature List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Programmingkid Cc: Peter Maydell , qemu-devel qemu-devel This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --SGpU5TrHaFjsmAS8rJMNIxf7hJHoAaSmi Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 29.08.2015 17:57, Programmingkid wrote: >=20 > On Aug 29, 2015, at 11:40 AM, Max Reitz wrote: >=20 >> 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 "Moun= t >>> 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 wa= nts >>> 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 managemen= t >> 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. >=20 > Isn't Libvirt only available on Linux? This mount image file feature wo= uld > 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). > Mac OS X users don't have all the fancy GUI wrappers > for QEMU :( Good thing most GNU/Linux distributions are free. ;-) (sorry, could not resist) > Mac OS X is a second-class citizen in the QEMU world... Might have to do something with most (?) of it being non-free and Apple not caring enough about KVM. (And without KVM, people in turn don't care enough about OS X as a qemu host.) ((But all of that is pretty biased speculation, of course.)) >> 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=85 >=20 > That is because of several reasons. One being maintainers not wanting t= o > advance the GUI because they feel another program should be QEMU's=20 > 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= =2E 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. 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) >> If we didn't care about that, than we'd have to think about the >> implementation. Internally, we'd probably call QMP's blockdev-add to >> open the image file, and then QMP's device_add to add the USB device. = So >> then qemu would use its own management interfaces to execute the >> operation, which seems a bit strange to me, further hinting at the fac= t >> that we probably should leave this to the management layer. >=20 > What works does, and it isn't always as nice looking > as we want it. I am sure we will use some kind of API to implement this= feature. Having to deal with ugly legacy cruft from time to time, I don't know whether "What works, works" is always appropriate. > I just wish there were an easy way to share files between the host and = the guest. I don't think using emulated USB storage is the right way to do this, though. Stefan is working on file sharing using NFS over virtio-vsock, which seems more appropriate. But then again I don't whether virtio-vsock will work with an OS X host=85 =3D=3D=3D OK, if you really want to implement it, I'm certainly not the right one to stop you, so here is how I'd do it: My "BlockBackend and media" series rewrites the "change" HMP/QMP command to be a macro, basically, that actually executes four lower-level QMP commands. So this means we have a precedent of "macro" QMP commands, and this could be extended. So you could add a "macro" QMP command "usb-storage-insert-file" or something which executes blockdev-add + device_add (if that works).* Then, if I felt really fancy, I'd add some layer which allows generically executing QMP commands through the GUI, based on a whitelist of commands. Each parameter would have to be requested through some GUI interface, for instance, filenames would be queried through an appropriate dialog. Ideally, this would be GUI-agnostic, but this may not be reasonably possible. Then you'd whitelist usb-storage-insert-file (or however it is named), give it some nice alias and you'd be done. While this would be much work I feel like this would actually be the nicest solution. This is just a very rough outline, though, and since it somehow goes against everything qemu's GUI was used for so far (just the most basic things, basically nothing about controlling the VM except for Pause/Shutdown/Reboot) I have no idea how it would be received. Max *Actually you'd probably want a generic insert-storage-file which takes the kind of storage device to add as a parameter. --SGpU5TrHaFjsmAS8rJMNIxf7hJHoAaSmi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQEcBAEBCAAGBQJV4eA6AAoJEDuxQgLoOKytPKIH+gM/F8yDdJ4qbh8OhhYmFnDz 4NlITPNOFYClJIRse/HMQYXLfwXxUXOX8Mr5iN7AaTzSOPFl7wFo1bkqnpNJbK0f w/o791arWGG2YpKt5wkwFA1YapvVSN0A9iP550rwZ7wWQloyvlcPehj9kX7duAT7 wGIqqThlRAbGNEYtWNt8Ro6hvcQWDWaM10W9P6vambSZtCzyKc9D4EspLW7HAqZi r0xHEeUsOTyWODqTcKXn7oXoBobUF2OzFUgcivfLahQdAedAyLrzgA4Ztr8Xq5BT 4eC9vo0WAIw7da3xDMi0lAW8ylHtTJ2be3gjGq53S4EV2fnjv0jsqzmHi7zmcjU= =Nbii -----END PGP SIGNATURE----- --SGpU5TrHaFjsmAS8rJMNIxf7hJHoAaSmi--