[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <alpine.LFD.2.02.1205072243500.6271@ionos>
Date: Mon, 7 May 2012 22:55:18 +0200 (CEST)
From: Thomas Gleixner <tglx@...utronix.de>
To: Sam Ravnborg <sam@...nborg.org>
cc: LKML <linux-kernel@...r.kernel.org>
Subject: Re: [patch 01/18] fork: Remove the weak insanity
On Sat, 5 May 2012, Sam Ravnborg wrote:
> On Sat, May 05, 2012 at 03:05:40PM -0000, Thomas Gleixner wrote:
> > We error out when compiling with gcc4.1.[01] as it miscompiles
> > __weak. The workaround with magic defines is not longer
> > necessary. Make it __weak again.
>
> The cleanup is much appreciated!
>
> But the magic defines is IMO much better than the CONFIG_ based approach
> that this patch-set introduces in the last patch.
>
> If you do:
>
> $git grep arch_task_cache_init
>
> Then if you see:
>
> #define arch_task_cache_init arch_task_cache_init
>
> Then you know alrady that this arch will provide a local implementation
> of arch_task_cache_init().
> No need to grep for an ARCH_XXX symbol that you need to look up
> somewhere else.
I'm not following that argument.
Removing that magic define thing does not change anything. The change
is:
-#define arch_task_cache_init arch_task_cache_init
-#define arch_task_cache_init arch_task_cache_init
-/*
- * macro override instead of weak attribute alias, to workaround
- * gcc 4.1.0 and 4.1.1 bugs with weak attribute and empty functions.
- */
-#ifndef arch_task_cache_init
-#define arch_task_cache_init()
-#endif
+void __init __weak arch_task_cache_init(void) { }
So $git grep arch_task_cache_init still tells you who is overriding
arch_task_cache_init () which is:
arch/sh/include/asm/thread_info.h:extern void arch_task_cache_init(void);
arch/sh/kernel/process.c:void arch_task_cache_init(void)
arch/x86/include/asm/thread_info.h:extern void arch_task_cache_init(void);
arch/x86/kernel/process.c:void arch_task_cache_init(void)
What's your problem ?
Now for the last patch in the series:
It merily moves
#define __HAVE_ARCH_THREAD_INFO_ALLOCATOR
to a Kconfig based
select ARCH_THREAD_INFO_ALLOCATOR
I'm not seeing any difference except that something which is actually
a config switch is moved to the place where it belongs.
Thanks,
tglx
--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
Powered by blists - more mailing lists