Re: [Qemu-devel] [PATCH] block: Deprecate bdrv_set_read_only() and users

["Daniel P. Berrange" <berrange@redhat.com>]

On Wed, Nov 08, 2017 at 12:51:27PM +0100, Kevin Wolf wrote:
> Am 08.11.2017 um 11:49 hat Daniel P. Berrange geschrieben:
> > On Wed, Nov 08, 2017 at 11:44:01AM +0100, Paolo Bonzini wrote:
> > > On 07/11/2017 18:39, Daniel P. Berrange wrote:
> > > > On Tue, Nov 07, 2017 at 06:26:38PM +0100, Kevin Wolf wrote:
> > > >> bdrv_set_read_only() is used by some block drivers to override the
> > > >> read-only option given by the user. This is not how read-only images
> > > >> generally work in QEMU: Instead of second guessing what the user really
> > > >> meant (which currently includes making an image read-only even if the
> > > >> user didn't only use the default, but explicitly said read-only=off), we
> > > >> should error out if we can't provide what the user requested.
> > > >>
> > > >> This adds deprecation warnings to all callers of bdrv_set_read_only() so
> > > >> that the behaviour can be corrected after the usual deprecation period.
> > > > 
> > > > All deprecations should be listed in "Deprecated features" appendix
> > > > in qemu-doc.texi. This probably fits in the 'system emulator command
> > > > line arguments' section, even though its talking about the need for
> > > > the user to add something extra, rather than deleting something they
> > > > currently use.
> > > 
> > > I am not sure this counts as deprecation, but it should go in the
> > > release notes as "future incompatible changes", and that section
> > > probably should go in qemu-doc.texi itself.
> > 
> > Yeah, adding a "Incompatible changes" appendix to the qemu-doc.texi
> > would be useful, listing the planned change, and when it is actually
> > made. That way apps adding support for a feature have an indication
> > of any incompatiblities they might need to care about.
> 
> You mean a section containing future incompatible changes as well as
> already implemented incompatible changes?
> 
> What would we do with the existing "Deprecated features" section? Would
> it become a subsection of "Incompatible changes"? Or would we just
> rename it and the subsections would stay on the same level and get
> "deprecated" added to their title? Or a completely different structure?

Yes, we could rename "Deprecated features" to "Deprecations & incompatible 
changes",  And then add the word "Deprecated" to the current @section
headings, and add a separate @section for things which are simply warning
about future incompatible changes which aren't strictly deprcations.


Regards,
Daniel
-- 
|: https://berrange.com      -o-    https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org         -o-            https://fstop138.berrange.com :|
|: https://entangle-photo.org    -o-    https://www.instagram.com/dberrange :|