LWN.net Logo

Re: [GIT PULL] XFS update for 2.6.27-rc4

From:  Andrew Morton <akpm-AT-linux-foundation.org>
To:  Dave Chinner <david-AT-fromorbit.com>
Subject:  Re: [GIT PULL] XFS update for 2.6.27-rc4
Date:  Thu, 14 Aug 2008 16:03:27 -0700
Message-ID:  <20080814160327.bf2a2673.akpm@linux-foundation.org>
Cc:  geert-AT-linux-m68k.org, lachlan-AT-sgi.com, torvalds-AT-linux-foundation.org, linux-kernel-AT-vger.kernel.org, xfs-AT-oss.sgi.com, linux-m68k-AT-vger.kernel.org
Archive-link:  Article, Thread

On Fri, 15 Aug 2008 08:51:30 +1000
Dave Chinner <david@fromorbit.com> wrote:

> > |   CC      arch/m68k/kernel/asm-offsets.s
> > | In file included from linux/include/linux/mm_types.h:12,
> > |                  from linux/include/linux/sched.h:61,
> > |                  from linux/arch/m68k/kernel/asm-offsets.c:12:
> > | linux/include/linux/completion.h: In function 'try_wait_for_completion':
> > | linux/include/linux/completion.h:80: error: dereferencing pointer to incomplete type
> > | linux/include/linux/completion.h: In function 'completion_done':
> > | linux/include/linux/completion.h:99: error: dereferencing pointer to incomplete type
> > | make[3]: *** [arch/m68k/kernel/asm-offsets.s] Error 1
> > | make[2]: *** [prepare0] Error 2
> > | make[1]: *** [sub-make] Error 2
> > 
> > (cfr. http://kisskb.ellerman.id.au/kisskb/buildresult/42080/)
> > 
> > Apparently there was not sufficient time between entering linux-next and
> > Linus' tree to notice this breakage before, while the original patch was already
> > posted on July 11...
> 
> It spent the time between then and now in the -mm tree. Seems
> like nobody is building m68k out of -mm.

I test m68k build regularly, but only allmodconfig.

Our (complexity(config system) * complexity(header files)) is so large
that compilation testing doesn't prove anything useful.  You just have
to check your homework very carefully and don earplugs for the
inevitable explosions.

> I'm out for the next 3 days, but it seems to me that the easiest fix
> is to move that code out of the header (i.e. uninline them) so the
> patch below is only compile tested on x86_64 - I've got to go load a
> trailer and get moving...

I'll give it a whizz on a few architectures, but it looks quite safe
from here.  It looks like the uninlining was desirable from a
size/speed POV anyway.




(Log in to post comments)

Copyright © 2008, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds