Re: [Qemu-devel] [PATCH] block: Set cdrom device read only flag

[Markus Armbruster]

ronnie sahlberg <address@hidden> 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?