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

[Kevin Wolf <kwolf@redhat.com>]

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?

I'm okay with adding a little documentation in this patch if I know what
it should look like, but if it turns into a major overhaul of the
documentation on incompatible changes, it's probably out of scope for
this patch.

Kevin