From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from eggs.gnu.org ([208.118.235.92]:33055) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyiNE-0002ao-CU for qemu-devel@nongnu.org; Tue, 07 Aug 2012 07:54:57 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1SyiND-0002fR-Cu for qemu-devel@nongnu.org; Tue, 07 Aug 2012 07:54:56 -0400 Received: from oxygen.pond.sub.org ([78.46.104.156]:35183) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1SyiND-0002fA-6g for qemu-devel@nongnu.org; Tue, 07 Aug 2012 07:54:55 -0400 From: Markus Armbruster References: <20120802013242.GA18298@tuon.disenchant.local> <20120802021613.GB18298@tuon.disenchant.local> <20120802051952.GC18298@tuon.disenchant.local> <20120802072040.GD18298@tuon.disenchant.local> <501F9769.2000902@redhat.com> <87sjbzozq0.fsf@blackfin.pond.sub.org> Date: Tue, 07 Aug 2012 13:54:50 +0200 Message-ID: <87fw7ynchh.fsf@blackfin.pond.sub.org> MIME-Version: 1.0 Content-Type: text/plain Subject: Re: [Qemu-devel] [PATCH] block: Set cdrom device read only flag List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: ronnie sahlberg Cc: Kevin Wolf , libvir-list@redhat.com, qemu-devel@nongnu.org, Kevin Shanahan ronnie sahlberg writes: > Since pretty much every cdrom drive use scsi today, shouldnt the > readonly/writeable flag for MMC devices rather > be done down in the hw/scsi* code rather than the generic block code? There are two separate things that can be read-only: device models and BlockDriverStates. -drive's parameter readonly applies to the top BlockDriverState. Some device models default their read-only-ness to their BlockDriverState's. Examples: * Device models ide-cd and scsi-cd are always read-only. They don't care whether the BlockDriverState that backs them is. * Device model ide-hd is always read-write. It fails initialization when its BlockDriverState is read-only. * Device model scsi-hd supports both read-only and read-write. It's read-only iff its BlockDriverState is. * -drive if={ide,scsi},media=cdrom implies readonly=on, and creates an {ide,scsi}-cd device. * -drive if={ide,scsi},media=disk creates an {ide,scsi}-hd device (media=disk is the default). * -drive without readonly=on fails when the image isn't writable. > If/when/ever I get enough time I would like to port the writeable > dvd+r emulation I wrote for STGT to qemu. > > > In STGT, MMC/DVD devices can be either read-only or read-write. > If the filesize for the backing file is >0 bytes, it is assumed the > file is an iso image and that the file is a read-only iso image. > If filesize is ==0, then the file is opened read-write and is treated > as a "blank dvd+r disk that the initiator can write/burn to" I doubt keying on the backing file size is a good idea, too obscure. Why would keying on the BlockDriverState's read-only-ness not work?