On Saturday 13 June 2009, liqin.chen@xxxxxxxxxxxxx wrote:
>
> > This is a somewhat unusual way to express these functions. It seems
> > that you only have one implementation for each of them, so I wonder
> > why you keep them as function pointers. Do you plan to add more CPUs
> > in the future that do these differently?
> >
>
> S+core series have score7 core and score3 core, they use different ISA,
> this patch only include score7 code. We will provide score3 code latter.
Ok. Is the ISA similar enough that you still intend to provide binary
kernels that work on both, with just overriding a few functions?
If a kernel gets built only for one architecture or another, a compile-time
switch would be quicker than a runtime switch here.
A common way to express this kind of runtime dependency is to put all
the function pointers into a single data structure and just flip a
single pointer at boot time, e.g.
struct score_cpu_ops {
void (*flush_cache_all)(void);
void (*flush_cache_mm)(struct mm_struct *mm);
void (*flush_cache_range)(struct vm_area_struct *vma,
unsigned long start, unsigned long end);
void (*flush_cache_page)(struct vm_area_struct *vma,
unsigned long page, unsigned long pfn);
void (*flush_cache_sigtramp)(unsigned long addr);
void (*flush_icache_all)(void);
void (*flush_icache_range)(unsigned long start, unsigned long end);
void (*flush_data_cache_page)(unsigned long addr);
};
extern struct score_cpu_ops *score_cpu_ops;
static inline flush_cache_all(void)
{
return score_cpu_ops->flush_cache_all();
}
...
Arnd <><
--
To unsubscribe from this list: send the line "unsubscribe linux-arch" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
