From: Sergey Senozhatsky <senozhatsky@chromium.org>
To: Kees Cook <keescook@chromium.org>
Cc: Nathan Chancellor <nathan@kernel.org>,
Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
Sergey Senozhatsky <senozhatsky@chromium.org>,
Miguel Ojeda <ojeda@kernel.org>,
"Gustavo A . R . Silva" <gustavo@embeddedor.com>,
Nick Desaulniers <ndesaulniers@google.com>,
Bill Wendling <morbo@google.com>,
Justin Stitt <justinstitt@google.com>,
linux-kernel@vger.kernel.org, llvm@lists.linux.dev
Subject: Re: [PATCH] Compiler Attributes: counted_by: bump compiler versions
Date: Wed, 10 Jan 2024 11:56:14 +0900 [thread overview]
Message-ID: <20240110025614.GA1282549@google.com> (raw)
In-Reply-To: <202401091311.08D6FF677@keescook>
On (24/01/09 13:12), Kees Cook wrote:
> > If I understand the doucmentation at [1] correctly, the first round of
> > testing starts with -rc1 and ends with -rc2, so if the feature is not
> > merged by -rc2, it won't make that release cycle. I think counted_by
> > might be a hard sell even after -rc1 because the feature is not exactly
> > small but it is also not expansive (it is relatively self contained
> > from what I can tell). So I think your plan is reasonable.
> >
> > Another alternative would be to split this patch in to three distinct
> > patches, not sure if that would be overkill for this though.
> >
> > 1. Update the clang review link from reviews.llvm.org to github.com
> > 2. Update the GCC version from 14 to 15.
> > 3. Update the Clang version from 18 to 19.
> >
> > The first two patches could be picked up immediately and the third one
> > could be sat on to see how the review and acceptance process works out
> > over the next couple of weeks. Up to you/Sergey. Thanks for taking a
> > look!
>
> Yeah, I think either the above split or just wait until the Clang 18
> cut, since we've got a while before the next kernel merge window.
Thanks everyone for the comments!
I'd probably prefer to split the patch and take the obvious and
trivial fixups now, and once clang -rc2 is tagged we can return
to clang min version requirement (if we won't forget :))
next prev parent reply other threads:[~2024-01-10 2:56 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2024-01-09 13:36 [PATCH] Compiler Attributes: counted_by: bump compiler versions Sergey Senozhatsky
2024-01-09 14:04 ` Gustavo A. R. Silva
2024-01-09 15:32 ` Nathan Chancellor
2024-01-09 19:42 ` Miguel Ojeda
2024-01-09 19:56 ` Nathan Chancellor
2024-01-09 21:12 ` Kees Cook
2024-01-10 2:56 ` Sergey Senozhatsky [this message]
2024-01-10 3:02 ` Sergey Senozhatsky
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=20240110025614.GA1282549@google.com \
--to=senozhatsky@chromium.org \
--cc=gustavo@embeddedor.com \
--cc=justinstitt@google.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=llvm@lists.linux.dev \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=morbo@google.com \
--cc=nathan@kernel.org \
--cc=ndesaulniers@google.com \
--cc=ojeda@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.