Re: [Qemu-devel] [PATCH v7 12/24] virtio-blk: Functions for op blocker management

[Kevin Wolf <kwolf@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 1719 bytes --]

Am 26.11.2015 um 08:48 hat Stefan Hajnoczi geschrieben:
> On Wed, Nov 25, 2015 at 05:26:02PM +0100, Max Reitz wrote:
> > On 25.11.2015 17:18, Kevin Wolf wrote:
> > > Am 25.11.2015 um 17:03 hat Max Reitz geschrieben:
> > >> On 25.11.2015 16:57, Kevin Wolf wrote:
> > >>> Am 09.11.2015 um 23:39 hat Max Reitz geschrieben:
> > >>> This makes me wonder: What do we even block here any more? If I didn't
> > >>> miss anything, it's only BLOCK_OP_TYPE_BACKUP_TARGET, and I'm not sure
> > >>> why this needs to be blocked, or if we simply forgot to enable it.
> > >>
> > >> Well, even though in practice this wall of code doesn't make much sense,
> > >> of course it will be safe for potential additions of new op blockers.
> > >>
> > >> And of course we actually don't want these blockers at all anymore...
> > > 
> > > Yes, but dataplane shouldn't really be special enough any more that we
> > > want to disable features for it initially. By now it sounds more like an
> > > easy way to forget unblocking a new feature even though it would work.
> > > 
> > > So perhaps we should really just remove the blockers from dataplane.
> > > Then we don't have to answer the question above...
> > 
> > Well, maybe. I guess this is up to Stefan.
> 
> At this point blockdev.c and block jobs acquire/release AioContext,
> hence all these op blockers are being unblocked.  I think we can switch
> from whitelisting (unblocking) nearly everything to blacklisting
> (blocking) only things that aren't supported yet.

As I said, there is only one operation that isn't whitelisted today,
BLOCK_OP_TYPE_BACKUP_TARGET, and I would be surprised if it weren't just
a bug that it's not whitelisted yet.

Kevin

[-- Attachment #2: Type: application/pgp-signature, Size: 836 bytes --]