Re: [libvirt] [Qemu-devel] [PATCH] block: Set cdrom device read only flag
ronnie sahlberg <ronniesahlberg(a)gmail.com> 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?