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

[Peter Zijlstra <peterz@infradead.org>]

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.