>So, thinking about the names makes me want something like:
>
>	bus_space_read_region_*s
>

I was thinking about better names, too; even i hated  my ones
Jason objected to.

I'd like the method names to use a consistent and `mnemonic'/obvious
ordering for the following attributes:

   + direction (read/write/copy),
   + datum size (currently bytes)
   + byteorder ( integer datum vs bytestream datum)
   + multiplicity (for _multi_ methods)

Not necessarily in that order, but (like cgd) I do think read/write is
the most signficant attribute and should be first.

My idea is to redesign the names for datum size and byteorder by using
int and byte prefixes:

	bus_space{read,write}_N ->   bus_space_{read,write}_int{8,16,32,64}

where the _intN names suggest (to me, anyway) translation to CPU
byteorder for ints. I think these names are a good implicit reminder
of the alignment restrictions, too.

The new `bytestream' methods would be

	bus_space_{read,write}_byte{1,2,4,8}

where the byteN suffix indicates bytestream access.  Maybe Jason's
stream would be better here; I don't know.

Multi (if desired) gets tacked in between read/write and the datum
type/size, just as we do now.. 

The _copy_ and _region_ routines would follow the same naming pattern,
with _region_ and _copy_ going in the same place as _multi_ (as we do now).

Comments??