could some current.h files be simplified?

could some current.h files be simplified?

[Robert P. J. Day]

  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
========================================================================

could some current.h files be simplified?

[Vladimir Murzin]

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 at 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