Chris wrote:

> The 16-bit and 32-bit methods _should not_ be used for streams of
> bytes.  They are meant to access multi-byte data items, and accessing
> groups of single byte data items with them is _incorrect_.

That's ok, but missed my original question a bit. In the example I gave
I happen to have the chance to read a 16 bit value by two 8-bit reads
and hence can make up my own byte order as I like. That is not always 
the case.

Imagine a card interrupts and stores a 16 bit interrupt event identifier
in a special register. The interrupt routine fetches that value in one
read and clears the interrupt implicitly by this (the card is designed
that way, you may call it broken or not). This, in fact, is quite similar
to the io-processor to host-processor communication protocol on the active
ISDN card I'm currently fighting with. It simply would not be correct to
do two 8-bit reads, since that may swallow another interrupt issued in
the mean time. It may not even give the correct value, depending on the
cards decoding logic.

Now, as the things seem to be, I end up with a 16 bit value in unknown
byte order. How the hell should I, the poor driver writer, tell which 
byteorder it is if the driver is supposed to be MI?


Martin