From: Dominique Martinet <asmadeus@codewreck.org>
To: Greg Kroah-Hartman <gregkh@linuxfoundation.org>
Cc: Miguel Ojeda <miguel.ojeda.sandonis@gmail.com>,
linux-kernel <linux-kernel@vger.kernel.org>,
Rasmus Villemoes <linux@rasmusvillemoes.dk>,
Eli Friedman <efriedma@codeaurora.org>,
Christopher Li <sparse@chrisli.org>,
Kees Cook <keescook@chromium.org>, Ingo Molnar <mingo@kernel.org>,
Geert Uytterhoeven <geert@linux-m68k.org>,
Masahiro Yamada <yamada.masahiro@socionext.com>,
Joe Perches <joe@perches.com>,
Linus Torvalds <torvalds@linux-foundation.org>,
linux-sparse@vger.kernel.org
Subject: Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared
Date: Thu, 20 Sep 2018 01:05:04 +0200 [thread overview]
Message-ID: <20180919230504.GA20280@nautica> (raw)
In-Reply-To: <20180919211458.GA8757@kroah.com>
Greg Kroah-Hartman wrote on Wed, Sep 19, 2018:
> > > So, with this applied, does clang really build an arm32 kernel
> > > successfully? No other problem at all? And this isn't really a
> > > regression, arm32 never really worked with clang yet, right?
> >
> > To recap a bit: these two patches come from the "Compiler Attributes"
> > series which is meant as a general improvement.
>
> Ok, so that's not for regressions, that's fine.
I've not followed so closely, in particular I'm not sure if it's the
only problem with arm32 right now, but that is a regression - the
general serie is meant as an improvement, but these two patches fix
815f0ddb346c ("include/linux/compiler*.h: make compiler-*.h mutually
exclusive") which was taken in 4.19-rc1
(Miguel, perhaps a Fixes: tag might help remember that?)
> If these do not fix a regression, I don't see how they would be ready
> for 4.19-final.
So the rest of the series is not a regression and isn't ready for
4.19-final, these two would be, but only got tested by the handful of
people in Cc here ; so ultimately it's your call.
> > I am going to send a v5 of the entire series without these two
> > patches, based on -rc4 (or -next, which one do you prefer? I would say
> > these patches should be applied early in the -next branches, so that
> > everyone is ready for the change, given it "touches" every translation
> > unit).
>
> That's up to whomever takes these into their tree for linux-next
> inclusion. If you are about to break everything, then you might
> consider changing your patches so they do not do that :)
I think that was more or less his question, there is no maintainer for
these files, so who should that whomever be? :)
The thing is linux took this kind of patch directly last time, but
ideally it really should sink in -next for a bit...
(If no-one in Cc has anything included in -next I could take them in my
9p branch, but that is quite a bit out of scope from what I advertised
this branch as so I think it would be confusing ; I think it might
almost be best if Miguel will keep maintaining these in the future to do
his own request to inclusion in -next?)
--
Dominique Martinet
next prev parent reply other threads:[~2018-09-19 23:05 UTC|newest]
Thread overview: 21+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-09-18 16:55 [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19) Miguel Ojeda
2018-09-18 16:55 ` [PATCH v2 1/2] Compiler Attributes: naked was fixed in gcc 4.6 Miguel Ojeda
2018-09-18 16:55 ` [PATCH v2 2/2] Compiler Attributes: naked can be shared Miguel Ojeda
2018-09-18 17:34 ` Greg Kroah-Hartman
2018-09-18 18:56 ` Miguel Ojeda
2018-09-19 21:14 ` Greg Kroah-Hartman
2018-09-19 23:00 ` Miguel Ojeda
2018-09-20 6:00 ` Stefan Agner
2018-09-20 7:19 ` Greg Kroah-Hartman
2018-09-20 7:20 ` Greg Kroah-Hartman
2018-09-19 23:05 ` Dominique Martinet [this message]
2018-09-19 23:56 ` Miguel Ojeda
2018-09-20 0:10 ` Dominique Martinet
2018-09-20 7:22 ` Greg Kroah-Hartman
2018-09-20 7:36 ` Dominique Martinet
2018-09-20 7:49 ` Geert Uytterhoeven
2018-09-20 16:11 ` Miguel Ojeda
2018-09-20 12:18 ` Miguel Ojeda
2018-09-20 13:57 ` [PATCH v2 0/2] Compiler Attributes: (naked only, for v4.19) Greg Kroah-Hartman
2018-09-20 13:59 ` Greg Kroah-Hartman
2018-09-20 16:13 ` Miguel Ojeda
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=20180919230504.GA20280@nautica \
--to=asmadeus@codewreck.org \
--cc=efriedma@codeaurora.org \
--cc=geert@linux-m68k.org \
--cc=gregkh@linuxfoundation.org \
--cc=joe@perches.com \
--cc=keescook@chromium.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-sparse@vger.kernel.org \
--cc=linux@rasmusvillemoes.dk \
--cc=miguel.ojeda.sandonis@gmail.com \
--cc=mingo@kernel.org \
--cc=sparse@chrisli.org \
--cc=torvalds@linux-foundation.org \
--cc=yamada.masahiro@socionext.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.