> >for instance, should 'inw' and 'outw' byte-swap their arguments,
> >and/or how should they be swizzled to poke into memory at the right
> >place? as i understand it, the need to byte swap on amiga ISA
> >bridges is dependent on which particular bridge you're using.
>
> It's even worse than that. I'm afraid I was not thinking straight when
> I said that byteorder things are straightforward. The need for byte
> swapping depends even on the driver and even in one driver some things
> need to be swapped and some left alone.
>
> For example in the if_ed driver there is one word read than needs to
> be swapped if the NIC is not configured to m68k byteorder.
I don't buy this example. I _do not_ think that isa/if_ed should be
modified to use the big-endian mode on a big-endian machine, for a
couple of reasons:
(1) potential improper implementation of that feature in
cheep PeeCee hardware. 8-)
(2) because you're no longer using it as you'd use the real
ISA device. It no longer would work with the normal ISA
programming interfaces, and if the board manufacturer
got 'tricky' and pulled some "neat trick" in hardware to
add functionality to the chip, or something, it might
not work any longer.
I think that what i'm trying to get at is, e.g. there should be no
explicit cases in _any_ of the ISA drivers about the endianness of the
host machine. functions that are part of the ISA software interface
in the kernel (including inb, outb, etc., and various memory access
and copy functions, etc.) should do the right thing, and the drivers
should be written so that they work transparently.
i think that what i'm trying to get it is, "it's a PC ISA board, at
the hardware level it should be programmed as if it's in a PC," or as
close to that as possible.
chris