ronnie sahlberg <ronniesahlberg@xxxxxxxxx> 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?
--
libvir-list mailing list
libvir-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/libvir-list