[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-Id: <201204301415.56690.arnd@arndb.de>
Date: Mon, 30 Apr 2012 14:15:56 +0000
From: Arnd Bergmann <arnd@...db.de>
To: Stephen Boyd <sboyd@...eaurora.org>
Cc: linux-kernel@...r.kernel.org, linux-arch@...r.kernel.org
Subject: Re: [PATCH] Move most arches to asm-generic/current.h
On Tuesday 24 April 2012, Stephen Boyd wrote:
> diff --git a/include/asm-generic/current.h b/include/asm-generic/current.h
> index 5e86f6a..bbfb795 100644
> --- a/include/asm-generic/current.h
> +++ b/include/asm-generic/current.h
> @@ -1,9 +1,16 @@
> #ifndef __ASM_GENERIC_CURRENT_H
> #define __ASM_GENERIC_CURRENT_H
>
> +#include <linux/compiler.h>
> #include <linux/thread_info.h>
>
> -#define get_current() (current_thread_info()->task)
> +struct task_struct;
> +
> +static __always_inline struct task_struct *get_current(void)
> +{
> + return current_thread_info()->task;
> +}
> +
> #define current get_current()
>
> #endif /* __ASM_GENERIC_CURRENT_H */
Does this need to be an inline function rather than a macro? I think I
remember having trouble with header file dependencies when I tried making
it an inline function initially and I don't know if those have been
resolved.
I realize that the macro is ugly, but if you don't mind keeping it,
that would be the safer option in terms of breaking some architecture
in the process. If course if you can prove that all architectures using
the generic implementation can use the inline function, I'm all for
the change.
Aside from this, I very much like your patch.
Acked-by: Arnd Bergmann <arnd@...db.de>
Arnd
--
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