Re: [GIT PULL] Kbuild updates for v5.4-rc1

[Jessica Yu]

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