Messages in this thread | | | Subject | Re: New resources - pls, explain :-( | From | Jes Sorensen <> | Date | 12 Aug 1999 22:56:00 +0200 |
| |
>>>>> "Linus" == Linus Torvalds <torvalds@transmeta.com> writes:
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/
| |