On Wed, Apr 15, 2020 at 02:15:35PM +0200, Pavel Mores wrote:
> On Tue, Apr 14, 2020 at 07:05:03PM +0200, Rafael Fonseca wrote:
> > On Tue, Apr 14, 2020 at 6:06 PM Pavel Mores <pmo...@redhat.com> wrote:
> > >
> > > By the way, the approach taken here with bhyveDriver{Lock,Unlock}() might
> > > make
> > > sense with the whole series - implement e.g. virMutexInit() in terms of
> > > g_mutex_init() in the first phase and only then replace the actual
> > > virMutexInit() calls if considered beneficial...
> >
> > So you mean one patch doing 's/virMutex/GMutex' and then inside
> > virMutex*() we call the g_mutex_*() equivalent? And maybe make
> > virMutex*() `inline`?
>
> Yes - I mean, I'm not familiar enough with this to be sure off-hand that just
> doing a literal find & replace would work with no undesired side-effects, but
> conceptually yes, that's the idea.
>
> That's just a thought though - taking that approach would have broken the
> refactor into two more manageable & testable chunks but seeing as you've done
> the hard work already, there's no need to rework the series just because of
> me.
> :-)
Replacing the virMutex calls with GMutex APis in all callers is the
desirable approach. The goal of using GLib APIs is to remove any
libvirt specfic APIs which duplicate GLib. Thus re-writing virMutex
APIs impls to call GMutex is just delaying the desired end state where
virMutex ceases to exist.
Regards,
Daniel
--
|: https://berrange.com -o- https://www.flickr.com/photos/dberrange :|
|: https://libvirt.org -o- https://fstop138.berrange.com :|
|: https://entangle-photo.org -o- https://www.instagram.com/dberrange :|
