Hi Andrew,
After merging the akpm tree, linux-next builds (powerpc allmodconfig)
fail like this:
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?
--
Cheers,
Stephen Rothwell [email protected]
On Tue, Sep 24, 2013 at 8:06 PM, Stephen Rothwell <[email protected]> wrote:
> Hi Andrew,
>
> After merging the akpm tree, linux-next builds (powerpc allmodconfig)
> fail like this:
>
> 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).
Is this something new? This code hasn't changed in over two years, so
I'm surprised it suddenly broke.
> 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?
How about:
#ifndef MODULE
static int __init ehv_bc_console_init(void)
{
...
}
console_initcall(ehv_bc_console_init);
#endif
On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <[email protected]> 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?
On Wed, 25 Sep 2013, Andrew Morton wrote:
> On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <[email protected]> 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
That caught me too: include/asm-generic/vtime.h is a patch-unfriendly
0-length file in the git tree; I wonder what use it's supposed to have.
(And I'm not very keen on the growing trend for symlinks in the git tree.)
Hugh
On Wed, 25 Sep 2013 14:32:14 -0700 (PDT) Hugh Dickins <[email protected]> wrote:
> On Wed, 25 Sep 2013, Andrew Morton wrote:
> > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <[email protected]> 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
>
> That caught me too: include/asm-generic/vtime.h is a patch-unfriendly
> 0-length file in the git tree;
hm, this?
From: Andrew Morton <[email protected]>
Subject: include/asm-generic/vtime.h: avoid zero-length file
patch(1) can't handle zero-length files - it appears to simply not create
the file, so my powerpc build fails.
Put something in here to make life easier.
Cc: Hugh Dickins <[email protected]>
Signed-off-by: Andrew Morton <[email protected]>
---
include/asm-generic/vtime.h | 1 +
1 file changed, 1 insertion(+)
diff -puN /dev/null include/asm-generic/vtime.h
--- /dev/null
+++ a/include/asm-generic/vtime.h
@@ -0,0 +1 @@
+/* no content, but patch(1) dislikes empty files */
_
> I wonder what use it's supposed to have.
Frederic, can you please confirm that include/asm-generic/vtime.h is
supposed to be empty?
> (And I'm not very keen on the growing trend for symlinks in the git tree.)
ooh, that explains why I lost my arch/microblaze/boot/dts/system.dts.
On Wed, Sep 25, 2013 at 02:43:28PM -0700, Andrew Morton wrote:
> On Wed, 25 Sep 2013 14:32:14 -0700 (PDT) Hugh Dickins <[email protected]> wrote:
>
> > On Wed, 25 Sep 2013, Andrew Morton wrote:
> > > On Wed, 25 Sep 2013 11:06:43 +1000 Stephen Rothwell <[email protected]> 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
> >
> > That caught me too: include/asm-generic/vtime.h is a patch-unfriendly
> > 0-length file in the git tree;
>
> hm, this?
>
>
> From: Andrew Morton <[email protected]>
> Subject: include/asm-generic/vtime.h: avoid zero-length file
>
> patch(1) can't handle zero-length files - it appears to simply not create
> the file, so my powerpc build fails.
>
> Put something in here to make life easier.
>
> Cc: Hugh Dickins <[email protected]>
> Signed-off-by: Andrew Morton <[email protected]>
> ---
>
> include/asm-generic/vtime.h | 1 +
> 1 file changed, 1 insertion(+)
>
> diff -puN /dev/null include/asm-generic/vtime.h
> --- /dev/null
> +++ a/include/asm-generic/vtime.h
> @@ -0,0 +1 @@
> +/* no content, but patch(1) dislikes empty files */
> _
>
>
>
> > I wonder what use it's supposed to have.
>
> Frederic, can you please confirm that include/asm-generic/vtime.h is
> supposed to be empty?
Yep. I use <asm/vtime.h> to let archs override some CPP symbols. And if they
don't override these, they simply return the generic vtime.h file that is empty
and as such doesn't override anything.
May be that's an ugly way to handle this kind of override scenario but I
couldn't find a better mechanism.
Actually, a Kconfig symbol would do the trick. It just seemed to me like
an overkill at that time. But it may be better.
Thanks.
>
> > (And I'm not very keen on the growing trend for symlinks in the git tree.)
>
> ooh, that explains why I lost my arch/microblaze/boot/dts/system.dts.