Re: [PATCH v3 00/12] x86, kbuild: revert macrofying inline assembly code
From: Masahiro Yamada
Date: Tue Dec 18 2018 - 22:20:08 EST
On Wed, Dec 19, 2018 at 5:26 AM Nadav Amit <namit@xxxxxxxxxx> wrote:
>
> > On Dec 17, 2018, at 8:03 AM, Masahiro Yamada <yamada.masahiro@xxxxxxxxxxxxx> wrote:
> >
> > This series reverts the in-kernel workarounds for inlining issues.
> >
> > The commit description of 77b0bf55bc67 mentioned
> > "We also hope that GCC will eventually get fixed,..."
> >
> > Now, GCC provides a solution.
> >
> > https://na01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgcc.gnu.org%2Fonlinedocs%2Fgcc%2FExtended-Asm.html&data=02%7C01%7Cnamit%40vmware.com%7Cc43f433d8c6244de15f108d6643a49e4%7Cb39138ca3cee4b4aa4d6cd83d9dd62f0%7C0%7C0%7C636806598899962669&sdata=88UJ25RoiHik9vTCJKZV6%2F7xpzCGsvKb9LFg1kfEYL0%3D&reserved=0
> > explains the new "asm inline" syntax.
> >
> > The performance issue will be eventually solved.
> >
> > [About Code cleanups]
> >
> > I know Nadam Amit is opposed to the full revert.
>
> My name is Nadav.
Sorry about that.
(I relied on a spell checker. I should be careful about typos in people's name.)
> > He also claims his motivation for macrofying was not only
> > performance, but also cleanups.
>
> Masahiro, I understand your concerns and criticism, and indeed various
> alternative solutions exist. I do have my reservations about the one you
> propose, since it makes coding more complicated to simplify the Make system.
> Yet, more important, starting this discussion suddenly now after RC7 is
> strange.
I did not think this was so sudden.
When I suggested the revert a few weeks ago,
Borislav was for it.
I did not hear from the other x86 maintainers.
Anyway, it is true we are running out of time for the release.
> Anyhow, since itâs obviously not my call, please donât make it
> sound as if I am a side in the decision.
>
Not my call, either.
That's why I put the x86 maintainers in the TO list,
and other people in CC.
The original patch set went in via x86 tree.
So, its revert set, if we want,
should go in the same path.
Anyway, we have to do something for v4.20.
Maybe, discussing short-term / long-term solutions
separately could move things forward.
[1] Solution for v4.20
[2] Solution for future kernel
If we do not want to see the revert for [1],
the best I can suggest is to copy arch/x86/kernel/macros.s
to include/generated/macros.h
so that it is kept for the external module build.
(It is not literally included by anyone, but should work at least.)
For [2], what do we want to see?
--
Best Regards
Masahiro Yamada