From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([2001:4830:134:3::10]:33000) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZpdEa-00066F-IV for qemu-devel@nongnu.org; Fri, 23 Oct 2015 10:22:21 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZpdEZ-0001PO-Ao for qemu-devel@nongnu.org; Fri, 23 Oct 2015 10:22:20 -0400 References: <1445270025-22999-1-git-send-email-mreitz@redhat.com> <1445270025-22999-29-git-send-email-mreitz@redhat.com> <20151023132259.GB3797@noname.redhat.com> From: Max Reitz Message-ID: <562A4290.7090207@redhat.com> Date: Fri, 23 Oct 2015 16:22:08 +0200 MIME-Version: 1.0 In-Reply-To: <20151023132259.GB3797@noname.redhat.com> Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="M0Vri9x1K2Ef33ijeboSeG4BBXOUvb2NK" Subject: Re: [Qemu-devel] [PATCH v7 28/39] blockdev: Add blockdev-open-tray List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Kevin Wolf Cc: Alberto Garcia , qemu-block@nongnu.org, John Snow , qemu-devel@nongnu.org, Markus Armbruster , Stefan Hajnoczi This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --M0Vri9x1K2Ef33ijeboSeG4BBXOUvb2NK Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: quoted-printable On 23.10.2015 15:22, Kevin Wolf wrote: > Am 19.10.2015 um 17:53 hat Max Reitz geschrieben: >> Signed-off-by: Max Reitz >> --- >> blockdev.c | 49 +++++++++++++++++++++++++++++++++++++++++++= ++++++ >> qapi/block-core.json | 23 +++++++++++++++++++++++ >> qmp-commands.hx | 39 +++++++++++++++++++++++++++++++++++++++ >> 3 files changed, 111 insertions(+) >=20 >> + >> + if (blk_dev_is_medium_locked(blk)) { >> + blk_dev_eject_request(blk, force); >> + } else { >> + blk_dev_change_media_cb(blk, false); >> + } >=20 > This seems to be inconsistent with the command documentation: In the > case of a forced eject request, the tray is just unlocked, but not > opened. OK. I assumed that since the guest would be expected to open the tray by itself if @force was false, the emulated device would do the same if @force was true. So I'll call blk_dev_change_media_cb() after blk_dev_eject_request(), too, if @force is true. >> +## >> +# @blockdev-open-tray: >> +# >> +# Opens a block device's tray. If there is a block driver state tree = inserted as >> +# a medium, it will become inaccessible to the guest (but it will rem= ain >> +# associated to the block device, so closing the tray will make it ac= cessible >> +# again). >> +# >> +# If the tray was already open before, this will be a no-op. >> +# >> +# @device: block device name >> +# >> +# @force: #optional if false (the default), an eject request will be= sent to >> +# the guest if it has locked the tray (and the tray will not= be opened >> +# immediately); if true, the tray will be opened regardless = of whether >> +# it is locked >> +# >> +# Since: 2.5 >> +## >> +{ 'command': 'blockdev-open-tray', >> + 'data': { 'device': 'str', >> + '*force': 'bool' } } >=20 > This API makes it impossible for the management application to know > whether the tray has actually been opened or just an eject request has > been made. Yes, and I faintly remember having asked you and Markus on your opinion on this topic in last December. A related question I was even more concerned about was "If the tray is locked and an eject request has been sent, the eject issued by the guest may do something different than blockdev-open-tray would have done with an unlocked tray", with the issue being that the management application cannot prevent blockdev-open-tray from sending the unlock request. I considered actually making blockdev-open-tray and this "send-eject-request" two different commands, so that blockdev-open-tray would never send an eject request and just return an error if the tray is locked. As far as I remember, you (both?) convinced me to keep it a single command which would do what "pressing the button on a physical CD drive does". So I did that, and thus it's the same. Just when pressing that button, after sending this command you'll have to wait until the tray is open and you won't know whether the OS actually has any intention of doing so until you've waited for too long. > Is the expected use that management sets a timeout and waits for a > tray opened event? If so, worth documenting? That's probably what management software should do, yes, just like it is with the "eject" command right now. I considered the "the tray will not be opened immediately" enough, but feel free to tell me it is not. Max --M0Vri9x1K2Ef33ijeboSeG4BBXOUvb2NK 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 iQEcBAEBCAAGBQJWKkKRAAoJEDuxQgLoOKytwTYH/1MYZBK4Xad4TREa086dXSZa g+xSXgJLQdiy+UnsCjUwdbaJZM3zkSpeDCkhIbl/AQpZ41Yg8I3iv6HyRpeMopeH bEJrAo9BdU9kDDAG98P4whriFHpqoWbgX78i0mWEpSAtp7abENzRNAVdWloBcE2V ZXDYiue0OhBN2ak1zA5hE8gvamuvrxqwxZTV27e4QPzcKgeb/ZZgEyLoWJF6YFhJ b/RLNTXsEng6GXLRKO2uYvKJ/8TciHMEucpnPHLNnIugjY3nAH22dLfBfL88Fv51 18lpjl/RM9fHBFRnxyaxRH2eF/vSNMnpEosEAeqwFdH/cny+L8F9QiGIInLPyTs= =tP0K -----END PGP SIGNATURE----- --M0Vri9x1K2Ef33ijeboSeG4BBXOUvb2NK--