Message-ID: <CANiq72=C==Us7YjkzwVW7QHXnuGxHTowriYjX3Wsff19JO=uHw@mail.gmail.com>
Date:   Thu, 20 Sep 2018 01:56:38 +0200
From:   Miguel Ojeda <miguel.ojeda.sandonis@...il.com>
To:     Dominique Martinet <asmadeus@...ewreck.org>
Cc:     Greg Kroah-Hartman <gregkh@...uxfoundation.org>,
        linux-kernel <linux-kernel@...r.kernel.org>,
        Rasmus Villemoes <linux@...musvillemoes.dk>,
        Eli Friedman <efriedma@...eaurora.org>,
        Christopher Li <sparse@...isli.org>,
        Kees Cook <keescook@...omium.org>,
        Ingo Molnar <mingo@...nel.org>,
        Geert Uytterhoeven <geert@...ux-m68k.org>,
        Masahiro Yamada <yamada.masahiro@...ionext.com>,
        Joe Perches <joe@...ches.com>,
        Linus Torvalds <torvalds@...ux-foundation.org>,
        linux-sparse@...r.kernel.org
Subject: Re: [PATCH v2 2/2] Compiler Attributes: naked can be shared

Hi Dominique,

On Thu, Sep 20, 2018 at 1:05 AM, Dominique Martinet
<asmadeus@...ewreck.org> wrote:
> 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?)

The commit is mentioned in the commit message, although not with the
Fixes: syntax -- is something now automatically parsing that? I guess
it is also easier for humans to parse :)

>
>> 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.
>

To further clarify about the series: it is probably fine for 4.19 with
the latest tests/reviews we did (v4), but it is too late for such a
change in the cycle (and due to this I am taking the chance to merge
the nonstring series into the Compiler Attributes one).

>
>> > 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...

Yeah, Linus is (was...) aware of it, so initially I thought Linus
would pick this whenever he felt it was ready.

>
> (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?)

I can ask for my auxdisplay tree (or better, a new one) to be in -next
and use that (are non-kernel.org trees allowed to be in -next, by the
way?).

Cheers,
Miguel

Powered by blists - more mailing lists