[Top][All Lists]

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

Re: [Qemu-devel] [PATCH 00/17] block: Convert common I/O path to BdrvChi

From: Paolo Bonzini
Subject: Re: [Qemu-devel] [PATCH 00/17] block: Convert common I/O path to BdrvChild
Date: Tue, 21 Jun 2016 11:47:21 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.1.1

On 21/06/2016 11:21, Kevin Wolf wrote:
> This series converts all I/O function in the core block layer up to
> bdrv_co_preadv/pwritev() to taking a BdrvChild as their first parameter
> instead of a BlockDriverState.
> The original motivation for this change were op blockers, where one of
> the biggest problems is making sure that every user of block devices
> actually registers correctly with the op blockers system. If the I/O
> functions know which parent a request comes from (BdrvChild basically
> corresponds to an edge in our block device graph), it can use assertions
> to make sure that that parent has actually registered its activities and
> thereby ensured that it doesn't conflict with other users.
> There are, however, more benefits we get from this change. The most
> important one is probably that it enforces important aspects of the
> block layer design like that external users go through a BlockBackend
> and request are internally routed along the edges of the graph. Accesses
> to random BDSes are no longer possible, you need to own an actual child
> reference so you can make a request.

I still fail to understand what is the rationale for this change.  The
API is weird; you read from a disk, not from an edge, and in fact the
first thing all the APIs do is dereference the BdrvChild...

The assertions are nice, but I'm not sure it's a good idea to design a
whole API around them.


> The work on this series already led to a few cleanups and BlockBackend
> conversions in master, and this series contains a few more.
> As a bonus, all the block drivers using bs->file->bs everywhere can now
> go back to bs->file, which is a little nicer to read.

reply via email to

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