On Thu, Jun 21, 2012 at 10:54:59AM -0400, Robert P. J. Day wrote:
it *seems* as if a number of current.h files from various architectures could be simplified. here's <asm-generic/current.h>, which gives any architecture a generic starting point in defining both get_current() and current:
#ifndef __ASM_GENERIC_CURRENT_H #define __ASM_GENERIC_CURRENT_H
#include <linux/thread_info.h>
#define get_current() (current_thread_info()->task) #define current get_current()
#endif /* __ASM_GENERIC_CURRENT_H */
and if that's acceptable, any architecture is welcome to simply include it as, for instance, mips does in <asm/current.h>:
#include <asm-generic/current.h>
but here's the current.h file for parisc:
#ifndef _PARISC_CURRENT_H #define _PARISC_CURRENT_H
#include <linux/thread_info.h>
struct task_struct;
static inline struct task_struct * get_current(void) { return current_thread_info()->task; }
#define current get_current()
#endif /* !(_PARISC_CURRENT_H) */
i'm not sure i see why the generic version wasn't adequate for parisc (apart from the explicit pointer casting). same thing with the cris architecture and, i'm sure, others.
is there any reason why some of those current.h files can't just include the generic one?
rday
--
======================================================================== Robert P. J. Day Ottawa, Ontario, CANADA http://crashcourse.ca
Twitter: http://twitter.com/rpjday LinkedIn: http://ca.linkedin.com/in/rpjday ========================================================================
_______________________________________________ Kernelnewbies mailing list Kernelnewbies@kernelnewbies.org http://lists.kernelnewbies.org/mailman/listinfo/kernelnewbies
Hi Robert There is sense to use generic version where it is suitable. I think you should propose you idea in linux-arch mail list. At least generalization of arches code is usually welcome. Best wishes Vladimir Murzin