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

[Fam Zheng <famz@redhat.com>]

On Tue, 06/21 13:31, Kevin Wolf wrote:
> Am 21.06.2016 um 13:01 hat Paolo Bonzini geschrieben:
> > On 21/06/2016 12:56, Kevin Wolf wrote:
> > > Am 21.06.2016 um 11:47 hat Paolo Bonzini geschrieben:
> > >> 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.
> > > 
> > > Do you see a problem with such an API, though? If there is no reason not
> > > to have the advantages, as small as they may seem, why not take them?
> > 
> > I don't see a reason not to take them; I don't see any red flags, but
> > there are some yellow flags (the kinda weird API) that I don't
> > understand and I hope you can explain.
> > 
> > Thinking more about it, it's perfectly possible that this is just a
> > combination of block/io.c's growth by accretion and the well-known fact
> > "naming pseudo-OOP member functions in C sucks".

I think this interface makes a lot of sense to me - I have been looking forward
to this model since three or four years ago, just without knowing ahead that
the object will be called BdrvChild, and that they'll occupy the first
parameter of bdrv_* API. I'm glad we are here today.

> > 
> > In other words, if you sell me this as "let's add some member functions
> > to BdrvChild and use them", I can buy it.  Perhaps the only thing to do
> > then is to rename functions and design a consistent naming.

And so I agree on renaming functions. :)

Fam

> 
> Hm, I never thought about it this way, but I think it actually makes
> sense.
> 
> As we want to represent a graph where both nodes and edges can have
> attributes and methods, OOP-wise both of them are objects, namely BDS
> and BdrvChild.
> 
> So we have some BDS A that has a Child B, and Child B in turn has a
> BDS C. What we used to do is that A asks B for the node it points to
> (C), and then directly calls a method of C. After the conversion, A
> calls a method of B, which in turn forwards the request by calling a
> method of C, which is much more straightforward and ideally even allows
> the node that B points to to remain private (we're not quite there,
> though).