Jamie Lokier wrote: > Anthony Liguori wrote: >> On 12/24/2009 03:09 AM, Markus Armbruster wrote: >>> Naphtali Sprei<nsp...@redhat.com> writes: >>> >>>> Added 'access' option to -drive flag >>>> >>>> The new option is: access=[rw|ro|auto] >>>> rw: open the drive's file with Read and Write permission, don't continue >>>> if failed >>>> ro: open the file only with Read permission >>>> auto: open the file with Read and Write permission, if failed, try only >>>> Read permision >>>> >>>> For compatibility reasons, the default is 'auto'. Should be changed later >>>> on. >>>> >>>> This option is to replace the 'readonly' options added lately. >>> Can we take the readonly parameter away? It's undocumented, for >>> whatever that's worth... >> readonly made 0.12. Semantics, readonly makes it to the disk emulation >> whereas this effects how the file is opened.
I'm not sure I understand this semantic difference. The implementation of both versions (readonly and access) affects both the disk emulation and the file access/open. I did meant that 'access' to replace the 'readonly', and I do understand that I did it in bad timing. > > With readonly in 0.12, if you _don't specify readonly, and the file is > opened readonly because it applies qemu's fallback behaviour - does > *that* read-only property make it to the disk emulation? Or do guests > still see unexplained I/O errors in that case? The implementation of both 'readonly' and 'access' pass the information to the Guest, through the device API. Indeed, only for supporting devices. > > Btw, wasn't the access=[rw|ro|auto] option supposed to affect disk > emulation too? > > -- Jamie
