Message-ID: <20190917180136.GA10376@linux-8ccs>
Date:   Tue, 17 Sep 2019 20:01:36 +0200
From:   Jessica Yu <jeyu@...nel.org>
To:     Masahiro Yamada <yamada.masahiro@...ionext.com>
Cc:     Linus Torvalds <torvalds@...ux-foundation.org>,
        Matthias Maennich <maennich@...gle.com>,
        Will Deacon <will@...nel.org>, gregkh@...uxfoundation.org,
        Linux Kbuild mailing list <linux-kbuild@...r.kernel.org>,
        Linux Kernel Mailing List <linux-kernel@...r.kernel.org>
Subject: Re: [GIT PULL] Kbuild updates for v5.4-rc1

+++ Masahiro Yamada [18/09/19 02:26 +0900]:
>Hi Jessica, Linus,
>
>On Wed, Sep 18, 2019 at 12:09 AM Jessica Yu <jeyu@...nel.org> wrote:
>>
>> +++ Masahiro Yamada [15/09/19 22:27 +0900]:
>> >Hi Linus,
>> >
>> >This is a Kbuild pull request for v5.4-rc1.
>> >I am sending this a bit earlier.
>> >Please pull it in when you open the merge window.
>> >
>> >Thanks.
>>
>> Hi Masahiro, Linus,
>>
>> There is a merge conflict between the kbuild and modules-next tree.
>>
>> Specifically, commits
>>
>>     69a94abb82e ("export.h, genksyms: do not make genksyms calculate CRC of trimmed symbols")
>>
>> and
>>
>>     9b9a3f20cbe ("kbuild: split final module linking out into Makefile.modfinal")
>>
>> from the kbuild tree caused some conflicts in modules-next in
>> include/linux/export.h and scripts/Makefile.modpost. The conflict
>> caused by 69a94abb82e in export.h is *non* trivial whereas the latter
>> commit involving Makefile.modpost is trivial.
>>
>> So there are a few options here..
>>
>> Solution #1: Masahiro pops the topmost 4 commits (down to 69a94abb82e)
>> from kbuild/for-next and I take them resolved through modules-next.
>> This would only leave the trivial conflict in Makefile.modpost left.
>> Send Linus the modules-next tree with a trivial resolution for
>> Makefile.modpost.
>
>
>No. I do not like to do it.
>
>
>Reason 1:
>Commit 69a94abb82e is a bug fix.
>On the other hand, the module name-space is a completely new feature.
>Why must the bug-fix commit rebased on top of the new feature commits?
>
>Reason 2:
>If 69a94abb82e were moved to your branch,
>its commit log would become really strange because the module-next branch
>does not contain 15bfc2348d54

No problem, fair enough points.

>> Solution #2:
>> Matthias Maennich staged a merge resolution from his tree
>> (https://github.com/metti/linux/tree/modules-next_linux-kbuild) so
>> another solution might be that I merge kbuild/for-next into
>> modules-next, take Matthias' (CC'd) conflict resolution including his
>> Signed-off-by, and then take that to Linus.
>
>I do not mind this.  Please feel free to proceed.
>
>
>
>But, if you do not mind, I can propose one more solution.
>
>Solution #3
>
>Linus will pull this Kbuild PR.
>
>Then, Jessica will rebase the module-next branch on the latest Linus tree.
>
>Because nothing in the modules-next branch has been tested in linux-next yet,
>(the patches were queued after -rc8, but there was no linux-next
>release last week)
>there is no strong reason to keep them on v5.3-rc7, right?

Yikes, I did not catch Stephen Rothwell's email about pausing the
linux-next releases from Sept 5 until Sept 30
(https://lore.kernel.org/linux-next/20190904233443.3f73c46b@canb.auug.org.au/).

The modules-next namespace patches have been in since last Tuesday,
and my original plan was for them to catch at least a week of
linux-next time before sending the pull request. :-/ But that did not
happen due to the above.

So Linus, in light of the above realization, I'd say at this time - I
will still formally send a pull request with the merge conflicts
resolved with either solution #2 or #3, but merge at your own
discretion, it's fine to delay to the following release if you're
uncomfortable.

Thanks,

Jessica

Powered by blists - more mailing lists