Messages in this thread | | | From | Linus Torvalds <> | Date | Fri, 3 Nov 2023 08:17:01 -1000 | Subject | Re: [PATCH 1/2] cleanup: Add conditional guard support |
| |
On Thu, 2 Nov 2023 at 23:30, Peter Zijlstra <peterz@infradead.org> wrote: > > On Thu, Nov 02, 2023 at 03:40:11PM +0100, Oleg Nesterov wrote: > > > > To me > > > > guard(rcu); > > guard(spinlock, &lock); > > > > looks better than > > > > guard(rcu)(); > > // doesn't match scoped_guard(spinlock, &lock) > > guard(spinlock)(&lock); > > > > And this will make guard() consistent with scoped_guard(). [...] > That said; if we were to do this, then something like: > > #define __cond_guard(_name, _inst, _fail, args...) \ > CLASS(_name, _inst)(args); \ > if (!__guard_ptr(_name)(&_inst)) _fail > > #define cond_guard(_name, _fail, args...) \ > __cond_guard(_name, __UNIQUE_ID(guard), _fail, args) > > cond_guard(spinlock_try, return -EBUSY, &my_lock); > > Becomes possible. > > Linus, do you like that enough to suffer a flag day patch as proposed by > Oleg?
I don't find myself caring too much whether we have that "double grouping" of the guard type-vs-arguments or the "(type, arg...)" syntax.
I honestly think that "guard(spinlock)(&lock)" makes it more visually obvious that the first argument is the "type of guard", while "guard(spinlock, &lock)" makes it look like the two arguments are somehow at the same level, which they most definitely aren't.
But I also can't find it in myself to care too much about something that is so purely syntactic, and that I suspect should be abstracted away anyway to just become "guard_spinlock(&lock)" with a trivial helper macro.
Linus
| |