Re: [PATCH] Move most arches to asm-generic/current.h

From: Stephen Boyd
Date: Mon Apr 30 2012 - 12:35:38 EST


On 04/30/12 07:15, Arnd Bergmann wrote:
> 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.
>

I admit I haven't compile tested this on all the affected architectures.
Looking at the architectures that are migrated here I don't see any that
are defining get_current() as a macro except for alpha. Should I drop
alpha from the patch? Or would it be easier if someone threw this into
linux-next and see if it blows up?

In the meantime I can scrounge around for those kernel.org
cross-compilers and see if I can compile alpha.

--
Sent by an employee of the Qualcomm Innovation Center, Inc.
The Qualcomm Innovation Center, Inc. is a member of the Code Aurora Forum.

--
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/