From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1KOcYc-0005We-Cl for qemu-devel@nongnu.org; Thu, 31 Jul 2008 14:07:22 -0400 Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1KOcYZ-0005Uu-Oc for qemu-devel@nongnu.org; Thu, 31 Jul 2008 14:07:20 -0400 Received: from [199.232.76.173] (port=58381 helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1KOcYZ-0005Ui-8I for qemu-devel@nongnu.org; Thu, 31 Jul 2008 14:07:19 -0400 Received: from wf-out-1314.google.com ([209.85.200.169]:40077) by monty-python.gnu.org with esmtp (Exim 4.60) (envelope-from ) id 1KOcYY-0001uh-Oe for qemu-devel@nongnu.org; Thu, 31 Jul 2008 14:07:19 -0400 Received: by wf-out-1314.google.com with SMTP id 27so889972wfd.4 for ; Thu, 31 Jul 2008 11:07:15 -0700 (PDT) Message-ID: Date: Thu, 31 Jul 2008 21:07:14 +0300 From: "Blue Swirl" Subject: Re: [Qemu-devel] PATCH: Control over drive open modes for backing file In-Reply-To: <20080731160113.GA22997@shareable.org> MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline References: <20080731113120.GJ23888@redhat.com> <20080731133420.GD18548@redhat.com> <200807311446.56381.paul@codesourcery.com> <20080731135512.GF18548@redhat.com> <20080731160113.GA22997@shareable.org> Reply-To: qemu-devel@nongnu.org List-Id: qemu-devel.nongnu.org List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , To: qemu-devel@nongnu.org Cc: Paul Brook On 7/31/08, Jamie Lokier wrote: > Blue Swirl wrote: > > On 7/31/08, Daniel P. Berrange wrote: > > > On Thu, Jul 31, 2008 at 02:46:55PM +0100, Paul Brook wrote: > > > > > +#define BDRV_O_RDONLY 0x0001 /* Force read-only */ > > > > > +#define BDRV_O_WRONLY 0x0002 /* Force writeable, no fallback */ > > > > > +#define BDRV_O_RDWR 0x0003 /* Try writeable, fallback to read-only > > > > > */ > > > > > > > > This is IMHO really misleading. Normal O_* are not bitflags. The code uses > > > > these as bitflags sometimes, which means your descriptions are contradictory. > > > > > > > > > One alternative approach I considered would be to not have an explicit > > > flag for writable, and instead have a flag to explicitly indicate that > > > fallback to read-only shouldn't be attempted. > > > > > > > > > #define BDRV_O_RDONLY 0x0001 > > > > > > #define BDRV_O_NO_RO_FALLBACK 0x0002 > > > > > > This would probably make the patch smaller because I won't need to update > > > all the callers which assume flags of '0' gives a writable file, falling > > > back to RO. > > > > > > Other suggestions welcome too... > > > > Write-only should mean that only writing is allowed, read access > > should not be needed. > > > You can't write to most formats unless you can read the metadata. > Flat is the exception, but WRONLY doesn't seem particularly useful. I also could not think of any use cases of write-only, but maybe write-only+append could be used for system logs. Presenting this through block device layers could be difficult, maybe a tape device with non-working seek? Not very useful even then.