From: Will Deacon <will.deacon@arm.com>
To: Mark Rutland <mark.rutland@arm.com>
Cc: linux-kernel@vger.kernel.org, peterz@infradead.org, boqun.feng@gmail.com
Subject: Re: [PATCHv2 08/11] atomics: switch to generated fallbacks
Date: Wed, 4 Jul 2018 18:44:52 +0100 [thread overview]
Message-ID: <20180704174451.GE9668@arm.com> (raw)
In-Reply-To: <20180704160145.kyzzymyufv3kt52l@lakrids.cambridge.arm.com>
On Wed, Jul 04, 2018 at 05:01:46PM +0100, Mark Rutland wrote:
> On Wed, Jul 04, 2018 at 04:28:47PM +0100, Will Deacon wrote:
> > On Mon, Jun 25, 2018 at 11:59:49AM +0100, Mark Rutland wrote:
> > > As a step to ensuring the atomic* APIs are consistent, switch to fallbacks
> > > generated by gen-atomic-fallback.sh.
> > >
> > > These are checked in rather than generated with Kbuild, since:
> > >
> > > * This allows inspection of the atomics with git grep and ctags on a
> > > pristine tree, which Linus strongly prefers being able to do.
> > >
> > > * The fallbacks are not expected to change very often, and are not
> > > affected by machine details or configuration options, so regenerating
> > > them for *every* build is somewhat wasteful.
> > >
> > > * These are included by files required *very* early in the build process
> > > (e.g. for generating bounds.h), and we'd rather not complicate the
> > > top-level Kbuild file.
> >
> > Would it be worth checking that the generated output from the script doesn't
> > differ from the file in tree at some point during the build, and issuing a
> > warning if they do?
>
> We could do that in the top-level Kbuild file. It would be less hideous
> than the generation was, since we don't have to add dependencies to all
> other targets.
>
> I can take a look, if you'd like?
Yes, please. Might also be worth having your "THIS FILE IS GENERATED"
disclaimer before each function, as I completely missed it when I opened the
file since it just looks like part of the license and jumping around with
ctags might dump you halfway down the file.
Will
next prev parent reply other threads:[~2018-07-04 17:44 UTC|newest]
Thread overview: 35+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-06-25 10:59 [PATCHv2 00/11] atomics: generate atomic headers / instrument arm64 Mark Rutland
2018-06-25 10:59 ` [PATCHv2 01/11] atomic/tty: Fix up atomic abuse in ldsem Mark Rutland
2018-06-26 18:53 ` Andy Shevchenko
2018-06-26 19:30 ` Peter Zijlstra
2018-06-27 17:33 ` Andy Shevchenko
2018-06-25 10:59 ` [PATCHv2 02/11] atomics/x86: reduce arch_cmpxchg64*() instrumentation Mark Rutland
2018-06-25 10:59 ` [PATCHv2 03/11] atomics: simplify cmpxchg() instrumentation Mark Rutland
2018-06-25 11:38 ` Andrea Parri
2018-06-25 11:47 ` Dmitry Vyukov
2018-06-25 11:48 ` Mark Rutland
2018-06-25 10:59 ` [PATCHv2 04/11] atomics/treewide: instrument xchg() Mark Rutland
2018-06-25 10:59 ` [PATCHv2 05/11] atomics: instrument cmpxchg_double*() Mark Rutland
2018-06-25 10:59 ` [PATCHv2 06/11] atomics/treewide: rework ordering barriers Mark Rutland
2018-06-25 15:44 ` Mark Rutland
2018-07-04 15:06 ` Will Deacon
2018-07-04 15:56 ` Mark Rutland
2018-07-04 17:50 ` Will Deacon
2018-07-05 10:12 ` Mark Rutland
2018-07-05 16:25 ` Will Deacon
2018-06-25 10:59 ` [PATCHv2 07/11] atomics: add common header generation files Mark Rutland
2018-06-28 10:58 ` Mark Rutland
2018-06-28 11:46 ` Peter Zijlstra
2018-06-25 10:59 ` [PATCHv2 08/11] atomics: switch to generated fallbacks Mark Rutland
2018-07-04 15:28 ` Will Deacon
2018-07-04 16:01 ` Mark Rutland
2018-07-04 17:44 ` Will Deacon [this message]
2018-07-05 11:52 ` Mark Rutland
2018-06-25 10:59 ` [PATCHv2 09/11] atomics: switch to generated atomic-long Mark Rutland
2018-06-25 10:59 ` [PATCHv2 10/11] atomics: switch to generated instrumentation Mark Rutland
2018-06-25 10:59 ` [PATCHv2 11/11] arm64: use instrumented atomics Mark Rutland
2018-07-04 15:24 ` Will Deacon
2018-07-04 16:37 ` Mark Rutland
2018-07-04 17:41 ` Will Deacon
2018-07-05 9:58 ` Mark Rutland
2018-06-25 15:22 ` [PATCHv2 00/11] atomics: generate atomic headers / instrument arm64 Peter Zijlstra
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=20180704174451.GE9668@arm.com \
--to=will.deacon@arm.com \
--cc=boqun.feng@gmail.com \
--cc=linux-kernel@vger.kernel.org \
--cc=mark.rutland@arm.com \
--cc=peterz@infradead.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox