From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:46103) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNPui-0002BS-G4 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 09:11:09 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNPuc-0001vi-QQ for qemu-devel@nongnu.org; Mon, 07 Nov 2011 09:11:04 -0500 Received: from mx1.redhat.com ([209.132.183.28]:30817) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNPuc-0001ve-Hy for qemu-devel@nongnu.org; Mon, 07 Nov 2011 09:10:58 -0500 Received: from int-mx12.intmail.prod.int.phx2.redhat.com (int-mx12.intmail.prod.int.phx2.redhat.com [10.5.11.25]) by mx1.redhat.com (8.14.4/8.14.4) with ESMTP id pA7EAvB6010408 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK) for ; Mon, 7 Nov 2011 09:10:57 -0500 Message-ID: <4EB7E767.1080601@redhat.com> Date: Mon, 07 Nov 2011 15:12:55 +0100 From: Kevin Wolf MIME-Version: 1.0 References: <1319540020-32484-1-git-send-email-pbonzini@redhat.com> <1319540020-32484-7-git-send-email-pbonzini@redhat.com> <4EB7DEDE.4090809@redhat.com> <4EB7E1D8.5090007@redhat.com> <4EB7E37D.4070903@redhat.com> In-Reply-To: <4EB7E37D.4070903@redhat.com> Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit Subject: Re: [Qemu-devel] [PATCH 6/8] block: add eject request callback List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Paolo Bonzini Cc: Markus Armbruster , qemu-devel@nongnu.org Am 07.11.2011 14:56, schrieb Paolo Bonzini: > On 11/07/2011 02:49 PM, Kevin Wolf wrote: >>> 2. eject with -f should really never be needed, but it does whatever is >>> needed to be able to follow up with a "change" command. It turns out it >>> is really "unlock" and "ask the guest to eject" combined, but that's the >>> implementation, not the model. >> >> Does this give different results than just asking the guest to eject >> without forcefully unlocking? I would expect that a guest that responds >> to the eject request would also unlock the drive. In which case I think >> eject without -f should be enough? > > Only if the guest is not buggy (e.g. locks the tray but stops polling > for eject requests) and has not crashed. If the guest is broken, forcefully unlocking and doing an eject request won't help either (the drive will be unlocked, but not ejected) and the only way to do anything useful with the drive is sending another eject command. This doesn't help with cleanly unmounting the medium, of course. So I think this is actually a point for the eject -f = paperclip model. Kevin