From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1NSJd4-0002yY-Tl for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:20:02 -0500 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1NSJcy-0002pd-CD for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:20:01 -0500 Received: from [199.232.76.173] (port=47409 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1NSJcy-0002pJ-5R for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:19:56 -0500 Received: from mail2.shareable.org ([80.68.89.115]:34570) by monty-python.gnu.org with esmtps (TLS-1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.60) (envelope-from ) id 1NSJcx-0006lH-00 for qemu-devel@nongnu.org; Tue, 05 Jan 2010 19:19:55 -0500 Date: Wed, 6 Jan 2010 00:19:50 +0000 From: Jamie Lokier Subject: Re: [Qemu-devel] [PATCH] Added 'access' option to -drive flag Message-ID: <20100106001950.GA25683@shareable.org> References: <4B320927.8020702@redhat.com> <4B42543C.4060506@codemonkey.ws> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <4B42543C.4060506@codemonkey.ws> List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: Anthony Liguori Cc: Naphtali Sprei , Markus Armbruster , qemu-devel@nongnu.org Anthony Liguori wrote: > On 12/24/2009 03:09 AM, Markus Armbruster wrote: > >Naphtali Sprei 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. 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? Btw, wasn't the access=[rw|ro|auto] option supposed to affect disk emulation too? -- Jamie