Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Tue, 13 Sep 2016 09:48:03 +0200
Arnd Bergmann  wrote:

> On Tuesday, September 13, 2016 2:02:57 PM CEST Stephen Rothwell wrote:
> > [For the new cc's, we are discussing the "thin archives" and "link dead
> > code/data elimination" patches in the kbuild tree.]
> > 
> > On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
> > wrote:  
> > >
> > > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:  
> > > >
> > > > On 2016-09-12 04:53, Nicholas Piggin wrote:
> > > > > Question, what is the best way to merge dependent patches? Considering
> > > > > they will need a good amount of architecture testing, I think they 
> > > > > will
> > > > > have to go via arch trees. But it also does not make sense to merge 
> > > > > these
> > > > > kbuild changes upstream first, without having tested them.  
> > > > 
> > > > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > > > if they are unused and untested. Any follow-up fixes required to enable
> > > > the first architecture can go through the respective architecture tree.
> > > > Does that sound OK?
> > > 
> > > And if you guarantee not to rebase the kbuild tree (or at least the
> > > subset containing these patches), then each of the architecture trees
> > > can just merge your tree (or a tag?) and then implement any necessary
> > > arch dependent changes.  I fixes are necessary, they can also be merged
> > > into the architecture trees.  
> > 
> > Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
> > patches that produce warnings on PowerPC  (And I am still reverting
> > the PowerPC specific one of those patches).  
> 
> Is that really powerpc specific? I have the same problem on ARM
> and I don't see how any architecture would not have it.
> 
> I prototyped the patch below, which fixes it for me, but I have
> not dared submit that workaround because it's butt ugly.

No it's not powerpc specific, it's just that powerpc build dies
if there are unresolved relocations.

Interesting approach. I have something different that may rival
yours for ugliness, but maybe keeps the muck a bit more contained.
I was just about to submit it, but now I'll wait to see if there is
a preference between the approaches:

(Note this patch alone does not resolve all export symbols, each
arch next needs to add C prototypes for their .S exports)

 scripts/Makefile.build | 71 +-
 1 file changed, 65 insertions(+), 6 deletions(-)

diff --git a/scripts/Makefile.build b/scripts/Makefile.build
index 11602e5..1e89908 100644
--- a/scripts/Makefile.build
+++ b/scripts/Makefile.build
@@ -158,7 +158,8 @@ cmd_cpp_i_c   = $(CPP) $(c_flags) -o $@ $<
 $(obj)/%.i: $(src)/%.c FORCE
$(call if_changed_dep,cpp_i_c)
 
-cmd_gensymtypes =   \
+# These mirror gensymtypes_S and co below, keep them in synch.
+cmd_gensymtypes_c = \
 $(CPP) -D__GENKSYMS__ $(c_flags) $< |   \
 $(GENKSYMS) $(if $(1), -T $(2)) \
  $(patsubst y,-s _,$(CONFIG_HAVE_UNDERSCORE_SYMBOL_PREFIX)) \
@@ -168,7 +169,7 @@ cmd_gensymtypes =   
\
 quiet_cmd_cc_symtypes_c = SYM $(quiet_modtag) $@
 cmd_cc_symtypes_c = \
 set -e; \
-$(call cmd_gensymtypes,true,$@) >/dev/null; \
+$(call cmd_gensymtypes_c,true,$@) >/dev/null;   \
 test -s $@ || rm -f $@
 
 $(obj)/%.symtypes : $(src)/%.c FORCE
@@ -197,9 +198,10 @@ else
 #   the actual value of the checksum generated by genksyms
 
 cmd_cc_o_c = $(CC) $(c_flags) -c -o $(@D)/.tmp_$(@F) $<
-cmd_modversions =  
\
+
+cmd_modversions_c =
\
if $(OBJDUMP) -h $(@D)/.tmp_$(@F) | grep -q __ksymtab; then 
\
-   $(call cmd_gensymtypes,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))
\
+   $(call cmd_gensymtypes_c,$(KBUILD_SYMTYPES),$(@:.o=.symtypes))  
\
> $(@D)/.tmp_$(@F:.o=.ver); 
\

\
$(LD) $(LDFLAGS) -r -o $@ $(@D)/.tmp_$(@F)  
\
@@ -267,13 +269,14 @@ endif # CONFIG_STACK_VALIDATION
 define rule_cc_o_c
$(call echo-cmd,checksrc) $(cmd_checksrc) \
$(call cmd_and_fixdep,cc_o_c) \
-   $(cmd_modversions)\
+   $(cmd_modversions_c)   

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Arnd Bergmann]

On Tuesday, September 13, 2016 2:02:57 PM CEST Stephen Rothwell wrote:
> [For the new cc's, we are discussing the "thin archives" and "link dead
> code/data elimination" patches in the kbuild tree.]
> 
> On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:
> > >
> > > On 2016-09-12 04:53, Nicholas Piggin wrote:  
> > > > Question, what is the best way to merge dependent patches? Considering
> > > > they will need a good amount of architecture testing, I think they will
> > > > have to go via arch trees. But it also does not make sense to merge 
> > > > these
> > > > kbuild changes upstream first, without having tested them.
> > > 
> > > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > > if they are unused and untested. Any follow-up fixes required to enable
> > > the first architecture can go through the respective architecture tree.
> > > Does that sound OK?  
> > 
> > And if you guarantee not to rebase the kbuild tree (or at least the
> > subset containing these patches), then each of the architecture trees
> > can just merge your tree (or a tag?) and then implement any necessary
> > arch dependent changes.  I fixes are necessary, they can also be merged
> > into the architecture trees.
> 
> Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
> patches that produce warnings on PowerPC  (And I am still reverting
> the PowerPC specific one of those patches).

Is that really powerpc specific? I have the same problem on ARM
and I don't see how any architecture would not have it.

I prototyped the patch below, which fixes it for me, but I have
not dared submit that workaround because it's butt ugly.

Arnd

 arch/arm/include/asm/io.h |  7 ---
 arch/arm/kernel/entry-ftrace.S| 12 +---
 arch/arm/kernel/head.S| 12 ++--
 arch/arm/kernel/smccc-call.S  |  6 +-
 arch/arm/lib/ashldi3.S|  7 ++-
 arch/arm/lib/ashrdi3.S|  6 +-
 arch/arm/lib/bitops.h | 19 +++
 arch/arm/lib/bswapsdi2.S  |  5 +
 arch/arm/lib/changebit.S  |  6 ++
 arch/arm/lib/clear_user.S | 10 +++---
 arch/arm/lib/clearbit.S   |  6 ++
 arch/arm/lib/copy_from_user.S |  7 +--
 arch/arm/lib/copy_page.S  |  5 +
 arch/arm/lib/copy_to_user.S   | 11 +++
 arch/arm/lib/csumipv6.S   |  5 +
 arch/arm/lib/csumpartial.S|  4 
 arch/arm/lib/csumpartialcopy.S|  7 ++-
 arch/arm/lib/csumpartialcopygeneric.S |  1 -
 arch/arm/lib/csumpartialcopyuser.S|  7 ++-
 arch/arm/lib/div64.S  |  7 ++-
 arch/arm/lib/findbit.S| 23 ++-
 arch/arm/lib/getuser.S| 23 +++
 arch/arm/lib/io-readsb.S  |  4 
 arch/arm/lib/io-readsl.S  |  4 
 arch/arm/lib/io-readsw-armv3.S|  4 
 arch/arm/lib/io-readsw-armv4.S|  5 +
 arch/arm/lib/io-writesb.S |  5 +
 arch/arm/lib/io-writesl.S |  5 +
 arch/arm/lib/io-writesw-armv3.S   |  5 +
 arch/arm/lib/io-writesw-armv4.S   |  4 
 arch/arm/lib/lib1funcs.S  | 33 ++---
 arch/arm/lib/lshrdi3.S|  7 ++-
 arch/arm/lib/memchr.S |  4 
 arch/arm/lib/memcpy.S |  5 +
 arch/arm/lib/memmove.S|  7 ++-
 arch/arm/lib/memset.S |  7 +++
 arch/arm/lib/memzero.S|  6 ++
 arch/arm/lib/muldi3.S |  7 ++-
 arch/arm/lib/putuser.S| 13 +
 arch/arm/lib/setbit.S |  6 ++
 arch/arm/lib/strchr.S |  4 
 arch/arm/lib/strrchr.S|  4 
 arch/arm/lib/testchangebit.S  |  6 ++
 arch/arm/lib/testclearbit.S   |  6 ++
 arch/arm/lib/testsetbit.S |  6 ++
 arch/arm/lib/ucmpdi2.S| 12 +---
 arch/arm/mach-imx/ssi-fiq.S   |  6 +-
 scripts/Makefile.build| 15 ---
 48 files changed, 288 insertions(+), 98 deletions(-)

diff --git a/arch/arm/include/asm/io.h b/arch/arm/include/asm/io.h
index 51458d8273ad..95ca0beda6a9 100644
--- a/arch/arm/include/asm/io.h
+++ b/arch/arm/include/asm/io.h
@@ -317,10 +317,13 @@ extern void _memset_io(volatile void __iomem *, int, 
size_t);
 #define writesl(p,d,l) __raw_writesl(p,d,l)
 
 #ifndef __ARMBE__
+
+extern void mmioset(void *, unsigned int, size_t);
+extern void mmiocpy(void *, const void *, size_t);
+
 static inline void memset_io(volatile void __iomem *dst, unsigned c,
size_t count)
 {
-   extern void mmioset(void *, unsigned int, size_t);

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Nicholas Piggin]

On Tue, 13 Sep 2016 14:02:57 +1000
Stephen Rothwell  wrote:

> Hi Michal,
> 
> [For the new cc's, we are discussing the "thin archives" and "link dead
> code/data elimination" patches in the kbuild tree.]
> 
> On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
> wrote:
> >
> > On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:  
> > >
> > > On 2016-09-12 04:53, Nicholas Piggin wrote:
> > > > Question, what is the best way to merge dependent patches? Considering
> > > > they will need a good amount of architecture testing, I think they will
> > > > have to go via arch trees. But it also does not make sense to merge 
> > > > these
> > > > kbuild changes upstream first, without having tested them.  
> > > 
> > > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > > if they are unused and untested. Any follow-up fixes required to enable
> > > the first architecture can go through the respective architecture tree.
> > > Does that sound OK?
> > 
> > And if you guarantee not to rebase the kbuild tree (or at least the
> > subset containing these patches), then each of the architecture trees
> > can just merge your tree (or a tag?) and then implement any necessary
> > arch dependent changes.  I fixes are necessary, they can also be merged
> > into the architecture trees.  
> 
> Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
> patches that produce warnings on PowerPC :-( (And I am still reverting
> the PowerPC specific one of those patches).
> 

I'm working on a better patch to fix that (and to whitelist powerpc's
relocation checks to it does not get blamed for such breakage)
Although no guarantees about that yet.

However some of the enablement and subsequent patches I would like to
merge are quite architecture specific, and I would prefer them to go
via arch trees.

So I would like to see a kbuild branch with these 3 in it, if arch
maintainers (or specifically powerpc) would be willing to pull it in
their -next branches.

Thanks,
Nick

Re: linux-next: manual merge of the kbuild tree with Linus' tree

[Stephen Rothwell]

Hi Michal,

[For the new cc's, we are discussing the "thin archives" and "link dead
code/data elimination" patches in the kbuild tree.]

On Tue, 13 Sep 2016 09:39:45 +1000 Stephen Rothwell  
wrote:
>
> On Mon, 12 Sep 2016 11:03:08 +0200 Michal Marek  wrote:
> >
> > On 2016-09-12 04:53, Nicholas Piggin wrote:  
> > > Question, what is the best way to merge dependent patches? Considering
> > > they will need a good amount of architecture testing, I think they will
> > > have to go via arch trees. But it also does not make sense to merge these
> > > kbuild changes upstream first, without having tested them.
> > 
> > I think it makes sense to merge the kbuild changes via kbuild.git, even
> > if they are unused and untested. Any follow-up fixes required to enable
> > the first architecture can go through the respective architecture tree.
> > Does that sound OK?  
> 
> And if you guarantee not to rebase the kbuild tree (or at least the
> subset containing these patches), then each of the architecture trees
> can just merge your tree (or a tag?) and then implement any necessary
> arch dependent changes.  I fixes are necessary, they can also be merged
> into the architecture trees.

Except, of course, the kbuild tree still has the asm EXPORT_SYMBOL
patches that produce warnings on PowerPC :-( (And I am still reverting
the PowerPC specific one of those patches).

-- 
Cheers,
Stephen Rothwell