On Mon, Oct 07, 2002 at 01:45:35PM -0400, Nicolas Pitre wrote:
> Here's the IO macro issue: On some embedded platforms the IO bus is only 8
> bit wide or only 16 bit wide, or address lines are shifted so registers
> offsets are not the same, etc. All this because embedded platforms are
> often using standard ISA peripheral chipsets since they can be easily glued
> to any kind of bare buses or static memory banks.
>
> The nice thing here is the fact that only by modifying inb() and friends you
> can reuse most current kernel drivers without further modifications.
> However the modifs to inb() are often different whether the peripheral in
> question is wired to a static memory bank, to the PCMCIA space or onto some
> expansion board via a CPLD or other weirdness some hardware designers are
> pleased to come with. Hence no global inb() and friend tweaking is possible
> without some performance hit by using a runtime fixup based on the address
> passed to them.
we have all this problems on m68k as well (except that our speed
constraints aren't so terribly strict), don't give up too quickly.
A possible solution is to generate multiple object file from the
same source using a different set of defines for each one. The kbuild
system can already handle it using the CFLAGS_$@ rule and asm/io.h
can then select the appropriate macros for inb etc.
Where it starts to be more interesting is when there are module
interdependecies (like ne.c and e8390.c) or all the object files
are to be be linked into kernel. Perhaps EXPORT_SYMBOL() and
INIT_MODULE() could be tweaked to mangle the names according to
some special define.
Richard
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/
This archive was generated by hypermail 2b29 : Tue Oct 15 2002 - 22:00:43 EST