> However, if what you're accessing is logically a byte stream (e.g. a
> string, or an ethernet packet) where you need the byte ordering to
> remain constant, that doesn't work so well.

OK.  I get it...
This is, in fact, what the smc91cxx driver should be using instead of
bus_space_read/write_multi_2() since its data register is a FIFO
mapped across 2 or 4 bytes (depending on the chip rev, we just use 2).

> When this problem was noticed, some of the BE systems folks (i forget
> who, now 8-), came up with the bus_space_*_stream_* methods.
> 
> They're the right thing, and every port should implement them (at
> least as no-ops).  And they should be documented.

I can handle the documentation and implementation on mac68k.  Right now,
though, bus_space_read_stream only shows up in bus.h for
	amiga
	arc
	atari
	bebox
	macppc
	prep
and	sh3

Since the bus_space_*_stream_ functions can be no-ops if the host cpu
and the bus are of the same endian, I guess most LE ports are fine (are
there any LE ports with non-LE busses?) and can just have a series of

#define bus_space_read_stream_1	bus_space_read_1
#define bus_space_read_stream_2	bus_space_read_2
#define bus_space_read_stream_4	bus_space_read_4
#define bus_space_read_stream_8	bus_space_read_8
...etc...
#define bus_space_read_multi_stream_1	bus_space_read_multi_1
...etc...
#define bus_space_read_region_stream_1	bus_space_read_region_1
...etc...
#define bus_space_write_stream_1	bus_space_write_1
...etc...
#define bus_space_write_multi_stream_1	bus_space_write_multi_1
...etc...
#define bus_space_write_region_stream_1	bus_space_write_region_1
...etc...

Is that right?  If so, would it be OK for me to update the bus.h for
the ports that I know to be solely LE?

Also, I notice that, for the most part, there is no
bus_space_set_region_stream_N defined.  Is that correct?  I don't really
see much of a need for this, although it might make sense to have it for
completeness.  I don't see a reason for _stream_ versions of copy_region
as they don't make sense.

Please help me get this right so I can get the documentation right...  ;-)
Right now, there is some float between implementations (as one might
expect since the specification is "like it was done over in X").

-allen