From: Linus Torvalds <torvalds@linux-foundation.org>
To: Nick Desaulniers <ndesaulniers@google.com>
Cc: Tom Rix <trix@redhat.com>, LKML <linux-kernel@vger.kernel.org>,
clang-built-linux <clang-built-linux@googlegroups.com>,
linux-toolchains@vger.kernel.org, Joe Perches <joe@perches.com>,
Julia Lawall <Julia.Lawall@lip6.fr>,
Masahiro Yamada <masahiroy@kernel.org>,
Nathan Huckleberry <nhuck15@gmail.com>
Subject: Re: Subject: [RFC] clang tooling cleanups
Date: Tue, 27 Oct 2020 12:39:18 -0700 [thread overview]
Message-ID: <CAHk-=wi0urcZx_TU=U5_hWEFbuwd67QV=7k7H5q7uWtvnV72kg@mail.gmail.com> (raw)
In-Reply-To: <CAKwvOd=83v0Sv-NhQ5xgqdNSRm2b=pOJDziX8axZ9t2YyYwz-A@mail.gmail.com>
On Tue, Oct 27, 2020 at 11:42 AM Nick Desaulniers
<ndesaulniers@google.com> wrote:
>
> Most recently Joe sent a treewide fix for section attributes that
> Linux pulled just after the merge window closed, IIUC. Maybe that
> would be the best time, since automation makes it trivial for anyone
> to run the treewide fixit whenever.
Well, it worked fine timing-wise, but the fact that it wasn't in
linux-next did mean that it then hit a few small snags once merged.
It's not a big deal - I never got the feeling that that patch was
rushed or that Joe hadn't vetted it enough, and it was well worth it,
but I'm pointing that out simply as an example of the model having a
few gotchas.
So avoiding linux-next (in order to avoid merge pain) does have
downsides. And even obvious and 100% automated fixes can cause issues
if there are #ifdef's or other architecture-specific things that then
mean that the extra semicolon might matter after all. Usually for
horribly bad reasons, but still..
So it would be best if this got a lot of multi-architecture (and
multi-config) coverage if it avoids linux-next.
Linus
next prev parent reply other threads:[~2020-10-27 19:39 UTC|newest]
Thread overview: 34+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-10-27 16:42 Subject: [RFC] clang tooling cleanups trix
2020-10-27 16:42 ` trix
2020-10-27 16:42 ` trix
2020-10-27 16:42 ` trix
2020-10-27 16:42 ` trix
2020-10-27 16:42 ` trix
2020-10-27 18:42 ` Nick Desaulniers
2020-10-27 19:33 ` Tom Rix
2020-10-27 19:51 ` Joe Perches
2020-10-27 20:50 ` Nick Desaulniers
2020-10-27 21:21 ` Tom Rix
2020-10-27 21:09 ` Tom Rix
2020-10-27 21:34 ` Joe Perches
2020-10-27 19:39 ` Linus Torvalds [this message]
2020-10-28 3:26 ` Finn Thain
2020-10-28 3:26 ` Finn Thain
2020-10-28 3:26 ` Finn Thain
2020-10-28 3:26 ` Finn Thain
2020-10-28 3:26 ` Finn Thain
2020-10-28 3:26 ` Finn Thain
2020-11-10 2:52 ` Subject: " Joe Perches
2020-11-10 2:52 ` Joe Perches
2020-11-10 2:52 ` Joe Perches
2020-11-10 2:52 ` Joe Perches
2020-11-10 2:52 ` Joe Perches
2020-11-10 2:52 ` [Cocci] " Joe Perches
2020-11-10 2:52 ` Joe Perches
2020-11-10 13:12 ` Tom Rix
2020-11-10 13:12 ` Tom Rix
2020-11-10 13:12 ` Tom Rix
2020-11-10 13:12 ` Tom Rix
2020-11-10 13:12 ` Tom Rix
2020-11-10 13:12 ` [Cocci] " Tom Rix
2020-11-10 13:12 ` Tom Rix
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='CAHk-=wi0urcZx_TU=U5_hWEFbuwd67QV=7k7H5q7uWtvnV72kg@mail.gmail.com' \
--to=torvalds@linux-foundation.org \
--cc=Julia.Lawall@lip6.fr \
--cc=clang-built-linux@googlegroups.com \
--cc=joe@perches.com \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-toolchains@vger.kernel.org \
--cc=masahiroy@kernel.org \
--cc=ndesaulniers@google.com \
--cc=nhuck15@gmail.com \
--cc=trix@redhat.com \
/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.