[libvirt PATCH v5 9/9] lxcDomainDetachDeviceHostdevUSBLive: Use VIR_WITH_OBJECT_LOCK_GUARD

Michal Prívozník mprivozn at redhat.com
Wed Feb 2 07:17:53 UTC 2022


On 2/2/22 01:06, Martin Kletzander wrote:
> On Tue, Feb 01, 2022 at 05:23:33PM +0100, Tim Wiederhake wrote:
>> On Tue, 2022-02-01 at 16:07 +0000, Daniel P. Berrangé wrote:
>>> On Tue, Feb 01, 2022 at 03:25:55PM +0100, Martin Kletzander wrote:
>>> > On Tue, Feb 01, 2022 at 02:20:17PM +0100, Tim Wiederhake wrote:
>>> > > Signed-off-by: Tim Wiederhake <twiederh at redhat.com>
>>> > > ---
>>> > > src/lxc/lxc_driver.c | 6 +++---
>>> > > 1 file changed, 3 insertions(+), 3 deletions(-)
>>> > >
>>> > > diff --git a/src/lxc/lxc_driver.c b/src/lxc/lxc_driver.c
>>> > > index 7bc39120ee..42053de9c3 100644
>>> > > --- a/src/lxc/lxc_driver.c
>>> > > +++ b/src/lxc/lxc_driver.c
>>> > > @@ -4045,9 +4045,9 @@
>>> > > lxcDomainDetachDeviceHostdevUSBLive(virLXCDriver *driver,
>>> > >         VIR_WARN("cannot deny device %s for domain %s: %s",
>>> > >                  dst, vm->def->name, virGetLastErrorMessage());
>>> > >
>>> > > -    virObjectLock(hostdev_mgr->activeUSBHostdevs);
>>> > > -    virUSBDeviceListDel(hostdev_mgr->activeUSBHostdevs, usb);
>>> > > -    virObjectUnlock(hostdev_mgr->activeUSBHostdevs);
>>> > > +    VIR_WITH_OBJECT_LOCK_GUARD(hostdev_mgr->activeUSBHostdevs) {
>>> > > +        virUSBDeviceListDel(hostdev_mgr->activeUSBHostdevs,
>>> > > usb);
>>> > > +    }
>>> >
>>> > Even nicer you can omit the curly brackets and make this a +2/-3 ;)
>>> > Otherwise I guess we'd need some kind of stylistic guide to keep us
>>> > consistent in this regard right from the start.
>>>
>>> My preference is the keep the scope of the guarded section explicit
>>> using {} even with a 1 line body.
>>
>> Same for me, fwiw.
>>
> 
> OK, I don't really have a horse in this race.  But in that case it would
> be nice
> to document it in our guidelines, maybe together with few words around
> the new
> macros.  In a later patch for example.

Since you brought this up, I vaguely remember us discussing this
earlier, though it was for one line body of if()-s. I too am in favor of
having curly braces in that case, except maybe when the body is a goto
or return statement. IOW:

  if (cond)
    return -1; // good

  if (cond) {
    func();  // good
  }

  if (cond) {
     goto cleanup; // not a big fan
  }

OTOH, consistency matters more so I can live with the last example too.

Michal




More information about the libvir-list mailing list