Subject: Re: bus.h style question
To: Chris G. Demetriou <>
From: Jonathan Stone <jonathan@DSG.Stanford.EDU>
List: tech-kern
Date: 08/16/1997 02:19:08
Chris G. Demetriou writes:

>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_.
>If you want to access multiple data items "efficiently" (regardless of
>their size) {read,write}_multi_* are the interfaces to use, and should
>be used with the correct data item size.

That is _not_ a technically accurate description of the bus_space
interface, either as used up to this point, or as documented, either
for the 1.2 version or for the -current/1.3 version.  If you want to
change the interface semantics to mean that, go head and do so, but
please don't lie to us about it being a change.

This restriction hasn't ever been documented as such, I've personlly
never been aware of any such restriction, I can't recall seeing it in
Jason's documentation (though I may be wrong there) and it isn't even
mentioned __anywhere__ in your bus_space(9) manual page, which is
completely silent as to byteorder issues. 

If you think the references to data width cover it, sorry, they don't.
I think The natural reading is that they refer to the width of the
hardware register being read, not to any higher-level interpretation
of the data as streams of either 8-bit or 16-bit data. (Yes, the
latter do exist: some serial-port FIFO registers are like that, with
status info in one byte and data in the other.)

I can see why you'd want your claim to be true: If the the bus_space
interface mandates single-byte-width methods for ``bytestream'' data,
then multibyte methods could do the byteswapping you want them to do,
and everything would Just Work.

And how *do* you propose to handle the problems of writing drivers for
PIO devices with wider-than-byte (16 or 32-bit) FIFO registers, using
only byte-width methods, when the hardware (bus or device) doesn't
support byte accesses the way it has to for this to work?

And even for devices where this does work, how about the efficiency
problems of a fourfold increase in the number of bus cycles?