From mboxrd@z Thu Jan  1 00:00:00 1970
Received: from eggs.gnu.org ([2001:4830:134:3::10]:42430)
	by lists.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aik@ozlabs.ru>) id 1VoBB1-0000wk-V8
	for qemu-devel@nongnu.org; Wed, 04 Dec 2013 07:03:43 -0500
Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71)
	(envelope-from <aik@ozlabs.ru>) id 1VoBAu-0003X9-Ll
	for qemu-devel@nongnu.org; Wed, 04 Dec 2013 07:03:35 -0500
Received: from mail-pd0-f176.google.com ([209.85.192.176]:42773)
	by eggs.gnu.org with esmtp (Exim 4.71)
	(envelope-from <aik@ozlabs.ru>) id 1VoBAu-0003Ww-FH
	for qemu-devel@nongnu.org; Wed, 04 Dec 2013 07:03:28 -0500
Received: by mail-pd0-f176.google.com with SMTP id w10so22132371pde.21
	for <qemu-devel@nongnu.org>; Wed, 04 Dec 2013 04:03:27 -0800 (PST)
Message-ID: <529F1A0A.80003@ozlabs.ru>
Date: Wed, 04 Dec 2013 23:03:22 +1100
From: Alexey Kardashevskiy <aik@ozlabs.ru>
MIME-Version: 1.0
References: <1386132925-16728-1-git-send-email-aik@ozlabs.ru>	<1386132925-16728-3-git-send-email-aik@ozlabs.ru>	<529EEFD0.4060801@redhat.com>
	<878uw1klh5.fsf@blackfin.pond.sub.org>
In-Reply-To: <878uw1klh5.fsf@blackfin.pond.sub.org>
Content-Type: text/plain; charset=KOI8-R
Content-Transfer-Encoding: 7bit
Subject: Re: [Qemu-devel] [PATCH 2/3] scsi-disk: check for meduim on
	ALLOW_MEDIUM_REMOVAL
List-Id: <qemu-devel.nongnu.org>
List-Unsubscribe: <https://lists.nongnu.org/mailman/options/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=unsubscribe>
List-Archive: <http://lists.nongnu.org/archive/html/qemu-devel>
List-Post: <mailto:qemu-devel@nongnu.org>
List-Help: <mailto:qemu-devel-request@nongnu.org?subject=help>
List-Subscribe: <https://lists.nongnu.org/mailman/listinfo/qemu-devel>,
	<mailto:qemu-devel-request@nongnu.org?subject=subscribe>
To: Markus Armbruster <armbru@redhat.com>, Paolo Bonzini <pbonzini@redhat.com>
Cc: Paul Mackerras <paulus@samba.org>, qemu-devel@nongnu.org

On 12/04/2013 08:35 PM, Markus Armbruster wrote:
> Paolo Bonzini <pbonzini@redhat.com> writes:
> 
>> Il 04/12/2013 05:55, Alexey Kardashevskiy ha scritto:
>>> This prevents the guest from preventing DVD medium removal when
>>> there is no medium.
>>>
>>> Without this, if the user has ejected a DVD, it is possible to
>>> have a block device with an open tray, no media but locked.
>>
>> I need to check this against a real disk.  Thanks!
> 
> If I remember correctly, I did, and it works.  You can still close the
> open tray in this state.


I thought it is about NOT letting close the open tray. So the hardware can
be programmed to ignore the hardware "eject" button when the tray is open?


-- 
Alexey