I have a processor which can run in big-endian mode and supports a PCI bus.

The problem is that this processor likes to auto-swap PCI accesses, so
that it matches the host CPU endianness.  (Meaning 32-bit reads are
converted from PCI little endian into native big-endian dwords on the host.)

This is probably a wonderful thing for performance for most things, but
I'm worried about two cases:

1) streaming reads/writes -- drivers that use these don't want the swap
-- so I guess I can provide a different bus implementation that swaps
for streaming accesses (if this sounds backwards it is because it is
backwards)

2) linear mappings.  Some device drivers out there (e.g. framebuffers)
expect to be able to linear map register or device memory.  (Some of the
occurrences of linear mappings are probably an error in the driver -- as
all the accesses occur thru bus_space_XXX routines).  If these drivers
don't know about the endian swap that automatically happens, it could be
bad.  (Machfb and igsfb explicity test for this, btw.)

Questions:

a) is a custom bus_space implementation the best way to handle this
nonsense.  The alternative, I suppose, is to just not support stream
operations on this bus.  (Which means that things like IDE and wi will
not work.)

b) should I support linear mappings of the bus space in case 2 (with the
result that some devices may give "unpredictable" results) or should I
just not support the linear mapping (which causes these devices to fail
cleanly in attach, but may exclude some things like machfb/igsfb that
can cope with this.

c) for devices that incorrectly use linear mappings but don't actually
use the linear mapping feature, should I try to fix them?  (examples:
if_vge.c does no direct accesses, if_ti.c does use them for descriptor
rings, but doesn't really need to)

d) should we provide some special bus_space mapping flag to indicate
that a bus endianness is assumed/required by the driver, which could be
used to provide for clean failures of bus_space_map when both linear and
endianness considerations cannot both be met?

Thanks!

-- 
Garrett D'Amore                          http://www.tadpolecomputer.com/
Sr. Staff Engineer          Extending the Power of 64-bit UNIX Computing
Tadpole Computer, Inc.                             Phone: (951) 325-2134