Re: linux-next: build failure after merge of the akpm tree

[Andrew Morton <akpm@linux-foundation.org>]

On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <sfr@canb.auug.org.au> wrote:

> Hi Andrew,
> 
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:

I can't get powerpc to build at all at present:

  CHK     include/config/kernel.release
  CHK     include/generated/uapi/linux/version.h
  CHK     include/generated/utsrelease.h
  CC      arch/powerpc/kernel/asm-offsets.s
In file included from include/linux/vtime.h:6,
                 from include/linux/hardirq.h:7,
                 from include/linux/memcontrol.h:24,
                 from include/linux/swap.h:8,
                 from include/linux/suspend.h:4,
                 from arch/powerpc/kernel/asm-offsets.c:24:
arch/powerpc/include/generated/asm/vtime.h:1:31: error: asm-generic/vtime.h: No such file or directory

> drivers/tty/ehv_bytechan.c:362:1: error: type defaults to 'int' in declaration of 'console_initcall' [-Werror=implicit-int]
> 
> Caused by commit 0f01cf96c2d4 ("./Makefile: enable -Werror=implicit-int
> and -Werror=strict-prototypes by default") which has bee in linux-next
> since Aug 16.  This commit exposed that fact that
> drivers/tty/ehv_bytechan.c can be built as a module, but has a
> console_initcall (which is not available to modules).  This was
> originally introduced in commit dcd83aaff1c8 ("tty/powerpc: introduce the
> ePAPR embedded hypervisor byte channel driver") in v3.2.
> 
> Anyone got a good solution?

console_initcall() is a macro defined in init.h.  But we forgot to
provide a version for #ifdef MODULE.

At include/linux/init.h line 284 we see:

/* Don't use these in loadable modules, but some people do... */
#define early_initcall(fn)		module_init(fn)
#define core_initcall(fn)		module_init(fn)
...

So we *could* add console_initcall() there.  But the problem is that it
won't work as desired - when the driver is loaded as a module,
ehv_bc_console_init() will be called at modprobe time, which is far far
later than console_initcall-time.

So the ehv_bytechan.c developers need to work out what they want to do
here.  Do we disallow building that driver as a module?  Or do we
permit that, and run ehv_bc_console_init() at modprobe time (needs
testing!).

If the latter then I'd be reluctant to add a modular version of
console_initcall() because the thing's very presence is misleading. 
otoh, drivers which use such a console_initcall() _might_ work, and
everyone tests their drivers both built-in and as modules, don't they? 
Don't they?