Am 26.10.2015 um 07:24 hat Fam Zheng geschrieben: > Drivers can have internal request sources that generate IO, like the > need_check_timer in QED. Since we want quiesced periods that contain > nested event loops in block layer, we need to have a way to disable such > event sources. > > Block drivers must implement the "bdrv_drain" callback if it has any > internal sources that can generate I/O activity, like a timer or a > worker thread (even in a library) that can schedule QEMUBH in an > asynchronous callback. > > Update the comments of bdrv_drain and bdrv_drained_begin accordingly. > > Signed-off-by: Fam Zheng <f...@redhat.com> > Reviewed-by: Jeff Cody <jc...@redhat.com> > Reviewed-by: Kevin Wolf <kw...@redhat.com> > --- > block/io.c | 6 +++++- > include/block/block_int.h | 6 ++++++ > 2 files changed, 11 insertions(+), 1 deletion(-) > > diff --git a/block/io.c b/block/io.c > index 358c3c4..a740827 100644 > --- a/block/io.c > +++ b/block/io.c > @@ -234,7 +234,8 @@ bool bdrv_requests_pending(BlockDriverState *bs) > } > > /* > - * Wait for pending requests to complete on a single BlockDriverState subtree > + * Wait for pending requests to complete on a single BlockDriverState > subtree, > + * and suspend block driver's internal I/O until next request arrives. > * > * Note that unlike bdrv_drain_all(), the caller must hold the > BlockDriverState > * AioContext. > @@ -247,6 +248,9 @@ void bdrv_drain(BlockDriverState *bs) > { > bool busy = true; > > + if (bs->drv && bs->drv->bdrv_drain) { > + bs->drv->bdrv_drain(bs); > + }
Does this need to be recursive? Recursing into bs->file and bs->backing would be consistent with the current bdrv_requests_pending(); but I'm planning to send a patch to extend this to all children. Kevin