Re: [Qemu-devel] PATCH: Control over drive open modes for backing file

[Blue Swirl]

On 7/31/08, Jamie Lokier <address@hidden> wrote:
> Blue Swirl wrote:
>  > On 7/31/08, Daniel P. Berrange <address@hidden> 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.