[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20230815203117.GA971582@hirez.programming.kicks-ass.net>
Date: Tue, 15 Aug 2023 22:31:17 +0200
From: Peter Zijlstra <peterz@...radead.org>
To: Andy Shevchenko <andriy.shevchenko@...ux.intel.com>
Cc: Linus Walleij <linus.walleij@...aro.org>,
Bartosz Golaszewski <brgl@...ev.pl>,
Kent Gibson <warthog618@...il.com>, linux-gpio@...r.kernel.org,
linux-kernel@...r.kernel.org,
Bartosz Golaszewski <bartosz.golaszewski@...aro.org>
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@...ev.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.
Powered by blists - more mailing lists