If you wanted max performance, you wouldn't issue reads over PCI :-)
Honestly, it's quite possible that any overhead from byteswaps would be
swamped by the bus latency, which is going to be hundreds of CPU clocks
on today's machines. (although as anecdotal evidence to the contrary,
we just squashed a bug in our linux driver that never surfaced in
our NT driver, because the NT bus macros evidently gave the chip just
enough extra time to recover after a reset. We don't want to lose that
performance edge, even if it cost me a day with a PCI analyzer.)
Actually, by the time I finished my last posting, calling for
little-endian and native-endian read/writes, I had managed to convince
myself that the right answer is really really fixed little-endian and
big-endian primitives, because the driver always knows the endian-ness
of the hardware. If that endian-ness is variable - a rather esoteric
case - then the driver knows about that, too, and can do the work to
deal with it.
This has the nice feature that I can write a driver for a normal device
on a little-endian machine without any #if-endian nonsense, and then
recompile and run it on a big-endian machine. Except that I can already
do that today - the only change this makes is to bring native bigendian
hardware (oddball PCI cards, NuBus, SBus) into the readl/writel fold,
a task which might be of more importance if people were making more new
cards for them...
(which brings up my confusion over Linus' definition of "PCI-like".
In prior lives I worked on 68K systems, and now I'm working on a PCI
card that has only memory regions, not I/O ones, so I guess I tend to
think of all I/O as memory-mapped, with in/out defining a weird separate
address space. I have a hard time figuring out a definition of PCI-like
that allows my card and PCI on an UltraSparc but excludes NuBus and SBus.)
-- ............................................................................ Peter Desnoyers Giganet Inc. 162 Pleasant St. (617) 661-1979 pjd@fred.cambridge.ma.us Cambridge, Mass. 02139 (978) 461-0402 (work) pjd@giga-net.com- 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/