+++ Masahiro Yamada [18/09/19 02:26 +0900]:
Hi Jessica, Linus,
On Wed, Sep 18, 2019 at 12:09 AM Jessica Yu <jeyu@xxxxxxxxxx> 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@xxxxxxxxxxxxxxxx/).
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
