> I think that for mixed CPU and bus byteorder, the natural usage is:
>   (a) for accessing device registers,  typically wants to
>       read and write one datum in CPU byteorder, so  byteswapped
>       (either by bridge or address prefrobnication) values, in
>       CPU byteorder, are what you want. CGD's example is perfect
>       here; if a 16-bit device register logically contains 0x1234,
>       you want the CPU to  get 0x1234 from a bus_space_read_2().

This is certainly true.  However, these functions are also used in
certain situations where (b) would be used, but can't because of other
constraints.  So, if you want "stream" versions of any of the
functions, you probably need "stream" versions of these.


>   (b) when moing PIO data to or from the device via FIFO
>       registers, you're moving bytestream data like disk or tape
>       blocks or Ethernet packets via bus_space_{read,write}_multi_N.
>       You want this data to go to the device registers as bytestream data,
>       so (assuming diferent-endian bus and CPU) you probably want the
>       _ opposite_ byteorder from case (a).

This (the claim that the primary need for these is "stream"-based)
might very well be true, but I don't think i'm willing to say that it
necessarily is.


>   (c) Dealing with bytestreams like disk or tape blocks or Ethernet
>       packets via a shared-memory buffer in bus space (e.g, ne2000),
>       using bus_space_{read,write}_region_N().
> 
>       Again, ignoring endian-agile I/O chips, I think you'd probably want
>       the opposite byte-order here from part (a), but it may well
>       depend on where the memory physically resides and how
>       the bus is wired up.

_if_ that's what you're using those functions for that.  _region_ has
other uses which typically _do_ want byte-swapping (if necessary),
e.g. frame buffer or VGA copies.


cgd