On Thu, 21 Aug 1997 06:59:18 -0700
   Jason Thorpe <thorpej@nas.nasa.gov> writes
>On Wed, 20 Aug 1997 03:33:11 -0700 
> Jonathan Stone <jonathan@DSG.Stanford.EDU> wrote:
>
> > Err,  actually I thought I was proposing semantics more like
> > 
> >      #define bus_space_read_swapped_2 (t, h, o) \
> >              NTOHS(bus_space_read_2(t, h, (o))

>UGH!  NO!  The methods should have much more abstracted names than that,
>and this doesn't even do the right thing!


I agree. All the example was poiting out was the problem in doing
multiple one-byte reads, and I noted the endian-ness problem in text
you snipped. (we still don't have any good MI names for `byteswap').


>Here is what the semantics, IMO, should be:
>
>        bus_space_{read,write}* - value is read from/written to bus space.
>        If the bus's "native" byte order is different from the CPU's, any
>        appropriate byte swapping _will_ occur.
>
>        (new entry points)
>        bus_space_stream_{read,write}* - value is read from/written to bus
>        space.  The values are treated as octet streams, thus bypassing
>        any byte swapping mechanisms.  Useful for e.g. 16-bit PIO access
>        to NE-2000 ethernet cards, manipulating VGA frame buffer data, etc.

Fine with me. The "byteswap" name you (rightly) object
to was for uh, expositional purposes.

But what names do you propose for the bytestream-oriented _multi_ and
_region_ methods??  Those are what I think are most likely to be
useful, and I can't follow the logic that decides whether adjectives
like multi/region/stream are prefixes {read, write}, or suffixes ...