[Spice-devel] [PATCH 04/14] reds: Put PipeItem first in VDIReadBuf

[Jonathon Jongsma]

On Mon, 2016-04-11 at 09:40 +0200, Christophe Fergeau wrote:
> On Fri, Apr 08, 2016 at 03:33:03PM -0500, Jonathon Jongsma wrote:
> > I don't know if something got messed up during a rebase (that doesn't appear
> > to
> > be the case), but I don't really understand this commit or how the patch
> > relates
> > to the commit log...
> > 
> 
> Fairly cryptic indeed, and it does not seem to have been impacted by
> rebases... :)
> The shortlog should be s/PipeItem/RingItem, and then what it means is
> that with this change, the layout of the VDIReadBuf struct makes it
> close enough to RedPipeItem (the refcounted one), that we can replace
> it.
> Layout becomes:
> 
> typedef struct VDIReadBuf {
>     RingItem link;
>     uint32_t refs;
>     ....
> }
> 
> 
> which is close enough to
> 
> typedef struct PipeItem {
>     RingItem link;
>     int type;
> } PipeItem;
> 
> 
> typedef struct {
>     PipeItem parent;
> 
>     /* private */
>     int refcount;
> 
>     GDestroyNotify free_func;
> } RedPipeItem;
> 
> So we can abuse the RedPipeItem stuff to get refcounting there. Given
> the subsequent "HACK" commit, maybe this is not such a good idea, and
> these VDIReadBuf changes could be dropped if they don't bring other
> benefits some place else.
> 
> Christophe


OK, that makes sense now. However, I don't really see any benefit in this as a
separate intermediate commit. I'd prefer to squash it with the next one. What do
you think?