Linus> I think we'll just define "readl()" to to be little-endian, and
Linus> then that problem is gone. That takes care of 99% of the market
Linus> right now, so it makes sense to just call it readl() - and let
Linus> the 1% then have to type four extra characters for
Linus> "vme_readl()" etc.
I know you have heard this before.
Having a readl_na() would make sense on big endian machines with PCI
busses since since some PCI cards (some gfx and network cards) will do
the translation for you in hardware making it look like the card is
native byte order. For 16 and 24 bit graphics for instance it is
absolutely not fun doing the byte swapping in software.
I do not want a readl_bigendian() for PCI since the result would be
that programmers would end up doing this to get a round it:
#ifdef BIG_ENDIAN
#define my_readl() readl_bigendian()
#else
#define my_readl() readl()
#endif
for every driver where big endian access makes sense which is pretty
silly IMHO.
I do not disagree with your vme_readl() proposal. Well it would be
nice if one could have a readl() that works for everybody but if one
wants to support 256 PCI busses in a box it might be a little
problematic.
Jes
-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.rutgers.edu
Please read the FAQ at http://www.tux.org/lkml/