Jonathan Stone wrote:

> I'm sure we could make drivers work without a byteswapping version of
> bus_space_{read,write}_multi_N, (n > 1) but we'd get better drivers
> for PIO devices if we did have them.

late in a discussion which again tried to explain the endianness issues 
of the bus_space_xxx stuff.

Let me get this straight... (as I'm currently implementing bus_space stuff
for NetBSD/Amiga). What I seem to have understood is this:

a) On machines, which _can_ have alien-endianness busses (more corretly: 
busses handled by bus_space_xxx of different endiannesses), the only
functions which _can_ be implemented as efficient inline macros are 
bus_space_xxx_1().

b) Independent of CPU endianness, the normal ISA bus bus_space_read_2(t, h, o)
function is equivalent to

	(bus_space_read_1(t, h, o) | (bus_space_read_1(t, h, (o)+1)<<8))

that is, it reads little-endian data items.

[Little-Endian CPUs can implement this more efficiently, but this is not the
point here]

c) Jonathan proposes to provide a bus_space_read_swapped_2(), which would be,
on little-endian busses like ISA, be equivalent to:

	(bus_space_read_1(t, h, (o)+1) | (bus_space_read_1(t, h, o)<<8))

d) Either one should take advantage of bridge hardware (meaning that the
bridge driver would decide, knowing what endianness the bus and the CPU have,
which functions to use, and maybe which alternative addressing of the bridge,
to do proper (non-)swapping.

e) expand this to the _multi_ and the _region_ stuff.

Regards,
	Ignatios