All of lore.kernel.org
 help / color / mirror / Atom feed
From: Peter Zijlstra <peterz@infradead.org>
To: Mitchell Levy <levymitchell0@gmail.com>
Cc: Geert Uytterhoeven <geert@linux-m68k.org>,
	Bartosz Golaszewski <brgl@bgdev.pl>,
	Andy Shevchenko <andriy.shevchenko@linux.intel.com>,
	"open list:GPIO SUBSYSTEM" <linux-gpio@vger.kernel.org>,
	Linux Kernel Mailing List <linux-kernel@vger.kernel.org>,
	Linus Walleij <linus.walleij@linaro.org>,
	Andy Shevchenko <andy@kernel.org>
Subject: Re: guard coding style (was: Re: [PATCH v1 05/10] gpio: pca953x: Simplify code with cleanup helpers)
Date: Fri, 15 Sep 2023 00:41:10 +0200	[thread overview]
Message-ID: <20230914224110.GA24799@noisy.programming.kicks-ass.net> (raw)
In-Reply-To: <20230914222639.GB5492@noisy.programming.kicks-ass.net>

On Fri, Sep 15, 2023 at 12:26:39AM +0200, Peter Zijlstra wrote:
> On Thu, Sep 14, 2023 at 01:51:01PM -0700, Mitchell Levy wrote:
> 
> > The more I think on this issue, the more I go back and forth. If we
> > only had guard(...), the only way to approximate scoped guard would be
> > to either just do what the macro does (i.e., a dummy for loop that
> > only runs once) or use an anonymous scope, e.g.,
> > {
> >     guard(...);
> >     my_one_statement();
> > }
> > Since this is how I've previously used std::lock_guard in C++, this
> > pattern feels very familiar to me, and the scoped_guard feels almost
> > like syntax sugar for this. As such, I feel like including the braces
> > is most natural because, as Geert mentioned, it emphasizes the scope
> > that "should" (in my brain, at least) be there.
> 
> AFAIC the anonymous scope thing doesn't much happen in kernel coding
> style -- although I'm sure it's there, the code-base is simply too vast
> to not have it *somewhere*.

The kernel typical style would be:

	do {
		...
	} while (0)

to create a 'pointless' scope. Apparently this is also what I've done in
some conversions where a conditional lock was involved.

  reply	other threads:[~2023-09-14 22:41 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-01 13:40 [PATCH v1 01/10] gpio: pca953x: Drop unused fields in struct pca953x_platform_data Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 02/10] gpio: pca953x: Fully convert to device managed resources Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 03/10] gpio: pca953x: Utilise dev_err_probe() where it makes sense Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 04/10] gpio: pca953x: Split pca953x_restore_context() and pca953x_save_context() Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 05/10] gpio: pca953x: Simplify code with cleanup helpers Andy Shevchenko
2023-09-13 14:35   ` Geert Uytterhoeven
2023-09-13 15:27     ` Bartosz Golaszewski
2023-09-14  7:47       ` guard coding style (was: Re: [PATCH v1 05/10] gpio: pca953x: Simplify code with cleanup helpers) Geert Uytterhoeven
2023-09-14 20:51         ` Mitchell Levy
2023-09-14 22:26           ` Peter Zijlstra
2023-09-14 22:41             ` Peter Zijlstra [this message]
2023-09-14 22:17         ` Peter Zijlstra
2023-09-14 22:30         ` Peter Zijlstra
2023-09-01 13:40 ` [PATCH v1 06/10] gpio: pca953x: Utilise temporary variable for struct device Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 07/10] gpio: pca953x: Utilise temporary variable for struct gpio_chip Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 08/10] gpio: pca953x: Switch to DEFINE_SIMPLE_DEV_PM_OPS() Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 09/10] gpio: pca953x: Get rid of useless goto label Andy Shevchenko
2023-09-04  7:41   ` Bartosz Golaszewski
2023-09-04  8:38     ` Andy Shevchenko
2023-09-01 13:40 ` [PATCH v1 10/10] gpio: pca953x: Revisit header inclusions Andy Shevchenko
2023-09-04  7:43 ` [PATCH v1 01/10] gpio: pca953x: Drop unused fields in struct pca953x_platform_data Bartosz Golaszewski
2023-09-06 16:26   ` Andy Shevchenko
2023-09-11  7:01 ` Bartosz Golaszewski
2023-09-12  7:50 ` Linus Walleij
2023-09-12  9:31   ` Andy Shevchenko
2023-09-12  9:48     ` Bartosz Golaszewski

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20230914224110.GA24799@noisy.programming.kicks-ass.net \
    --to=peterz@infradead.org \
    --cc=andriy.shevchenko@linux.intel.com \
    --cc=andy@kernel.org \
    --cc=brgl@bgdev.pl \
    --cc=geert@linux-m68k.org \
    --cc=levymitchell0@gmail.com \
    --cc=linus.walleij@linaro.org \
    --cc=linux-gpio@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.