qemu-block
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Qemu-block] [PATCH 3/5] block: Remove cache.writeback from blockdev


From: Kevin Wolf
Subject: Re: [Qemu-block] [PATCH 3/5] block: Remove cache.writeback from blockdev-add
Date: Mon, 14 Mar 2016 17:22:50 +0100
User-agent: Mutt/1.5.21 (2010-09-15)

Am 14.03.2016 um 17:10 hat Eric Blake geschrieben:
> On 03/14/2016 09:44 AM, Kevin Wolf wrote:
> > The WCE bit is a frontend property and should not be part of the backend
> > configuration. This is especially important because the same BDS can be
> > used by different users with different WCE requirements.
> > 
> > Signed-off-by: Kevin Wolf <address@hidden>
> > ---
> >  qapi/block-core.json | 4 +---
> >  1 file changed, 1 insertion(+), 3 deletions(-)
> > 
> > diff --git a/qapi/block-core.json b/qapi/block-core.json
> > index 9bf1b22..e3617e2 100644
> > --- a/qapi/block-core.json
> > +++ b/qapi/block-core.json
> > @@ -1614,7 +1614,6 @@
> >  #
> >  # Includes cache-related options for block devices
> >  #
> > -# @writeback:   #optional enables writeback mode for any caches (default: 
> > true)
> >  # @direct:      #optional enables use of O_DIRECT (bypass the host page 
> > cache;
> >  #               default: false)
> >  # @no-flush:    #optional ignore any flush requests for the device 
> > (default:
> > @@ -1623,8 +1622,7 @@
> >  # Since: 1.7
> >  ##
> >  { 'struct': 'BlockdevCacheOptions',
> > -  'data': { '*writeback': 'bool',
> > -            '*direct': 'bool',
> > +  'data': { '*direct': 'bool',
> >              '*no-flush': 'bool' } }
> 
> Observable through introspection.  Not quite backwards-compatible, but
> at least clients can learn about it, and arguably clients shouldn't have
> been using it.  I can accept it as a bug fix, even though it does risk
> breaking old clients that were trying to use it.
> 
> If it helps, libvirt does not seem to have been using it.

I think we declared that blockdev-add is still experimental, so it
should be okay.

And I was actually pondering whether this struct even makes sense any
more or whether we should move 'direct' and 'no-flush' directly to the
parent struct.

Kevin

Attachment: pgpyiBNs_xaDX.pgp
Description: PGP signature


reply via email to

[Prev in Thread] Current Thread [Next in Thread]