From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([140.186.70.92]:35841) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNRqJ-0000Kh-JL for qemu-devel@nongnu.org; Mon, 07 Nov 2011 11:14:45 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1RNRqI-0006aU-B5 for qemu-devel@nongnu.org; Mon, 07 Nov 2011 11:14:39 -0500 Received: from mail-qy0-f173.google.com ([209.85.216.173]:51785) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1RNRqI-0006aO-2F for qemu-devel@nongnu.org; Mon, 07 Nov 2011 11:14:38 -0500 Received: by qyk30 with SMTP id 30so3380274qyk.4 for ; Mon, 07 Nov 2011 08:14:37 -0800 (PST) Sender: Paolo Bonzini Message-ID: <4EB803E6.5010605@redhat.com> Date: Mon, 07 Nov 2011 17:14:30 +0100 From: Paolo Bonzini 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> In-Reply-To: Content-Type: text/plain; charset=ISO-8859-1; format=flowed 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: Markus Armbruster Cc: kwolf@redhat.com, qemu-devel@nongnu.org On 11/07/2011 04:23 PM, Markus Armbruster wrote: >> 1. eject without -f is as you mentioned. > > Would implementing the missing part help with the problem at hand? It would help for non-buggy guests. Buggy means even "echo -1 > /sys/block/sr0/events_poll_msecs". However, a full solution would require a change in management, and adding a TRAY_STATUS_CHANGED event to QEMU. Not sure this is required for 1.0, as it can even be added later to stable. >> 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. > > Physical hardware doesn't work that way (unless I misunderstand it). > Always a warning sign. True. >> The difference from the paperclip model is that it gives a chance for >> the OS to clean up and eject safely. It wouldn't be hard to convince >> me otherwise though, especially if it can help getting the patch in >> 1.0. The "eject -f"+"change" can be replaced by "eject", possibly >> followed by "eject -f" after a timeout, and then followed again by >> "change". > > On bare metal, the pressing the tray button accomplishes that: the drive > notifies the OS the button was pressed, the well-behaved OS cleans up > and ejects. With a misbehaving OS, you're reduced to the paperclip. > > Can't we replicate that? > > 1. Tray button / eject without -f > > A. when the tray is not locked: tray opens immediately. > > B. when the tray is locked: OS gets notified. We expect it to clean > up, unlock and open the tray at some point in the near future. > > 2. Paperclip / eject with -f > > Tray opens immediately. Guest OS may be unhappy about it. I now redid my tests with the paperclip behavior (it's really one line of different code) and everything seems to work. Will submit v2. Paolo