Re: [PATCH 2/2] gpio: sim: simplify code with cleanup helpers

From: Peter Zijlstra
Date: Tue Aug 15 2023 - 16:34:17 EST


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@xxxxxxxx> 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@xxxxxxxxxxxxx

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.