[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