Messages in this thread | | | Date | Tue, 15 Aug 2023 22:31:17 +0200 | From | Peter Zijlstra <> | Subject | Re: [PATCH 2/2] gpio: sim: simplify code with cleanup helpers |
| |
On Tue, Aug 15, 2023 at 06:58:10PM +0300, Andy Shevchenko wrote: > On Tue, Aug 15, 2023 at 05:52:53PM +0200, Peter Zijlstra wrote: > > On Tue, Aug 15, 2023 at 10:04:32AM +0200, Linus Walleij wrote: > > > On Wed, Aug 9, 2023 at 3:14 PM Bartosz Golaszewski <brgl@bgdev.pl> wrote: > > > > > > - mutex_lock(&chip->lock); > > > > + guard(mutex)(&chip->lock); > > > Looks about right. > > Btw, why don't we have something like > > guard_mutex() > > to be used as > > guard_mutex(&chip->lock);
Because this way I can write:
DEFINE_LOCK_GUARD_1(rq_lock_irqsave, struct rq, rq_lock_irqsave(_T->lock, &_T->rf), rq_unlock_irqrestore(_T->lock, &_T->rf), struct rq_flags rf);
And have:
guard(rq_lock_irqsave)(rq);
and
scoped_guard (rq_lock_irqsave, rq) { }
just work.
And if you look in tip/sched/core, you'll find exactly this.
Or look here:
https://lkml.kernel.org/r/20230612090713.652690195@infradead.org
for a bunch more examples -- I've wanted to get more of that merged, but alas, only 24h in a day and life got in the way. Defining local guard types is very useful.
> Moreover, maybe some macro that can predict the API call from the type of > the parameter?
The whole type inferrence in C is not extensible. That is, you get to write a single _Generic() statement, and every case that is included in it will work, but the moment you use a new type, one that is not included in your giant _Generic() statement, you're out of luck.
| |