| In message <20011019191335.26310.qmail@mail.netbsd.org>eeh@netbsd.org writes
|
| >However, the mere fact we are having this argument illustrates the brokenness
| >of the current semantics.
|
| not necessarily.  If (rusty) memory serves, the existing semantics
| deliberately avoids providing the full (read x write) barrier matrix
| of the proposed revision.

After spending some time reviewing the email archives, I have failed
to find any real discussion about the bus_space_barrier() interface.
So it's difficult to argue design.  However, it does seem to bear a
peculiar similarity to the instructions avaliable on alpha....

| Why? Because a lot of then-extant hardware simply can't do the full
| matrix. If a driver asks for a given barrier which the hardware can't
| do, then the implementation has to pick some stronger barrier, and do
| that instead. 

The issue here isn't how MD picks the appropriate barrier for a specific
operation.  The issue is how to map the current, loosely defined operations
to new, more stringently defined operations.

| I also recall a design choice that certain entries in the full R x W
| matrix simply wouldn't be used that often; and that the decision not
| to have a full matrix reflected that, as well as the inability of
| "common" hardware to do the full matrix.
|
| Isn't the real issue here to document a hierarcy of barriers, which
| define how an implementation should "round up" a requested barrier to
| what the hardware can acutally do?  (Isn't that what the current
| discussion really illustrates?)

The current definition of BUS_SPACE_BARRIER_READ only discusses 
interactions between read operations, and BUS_SPACE_BARRIER_WRITE
only discusses interactions between write operations.  The effects
of BUS_SPACE_BARRIER_READ on write operations is undefined, just as
the effect of BUS_SPACE_BARRIER_WRITE on read operations is also
undefined.  If you want to impose some order between bus_space_read()
operations and bus_space_write() operations, you need to use
BUS_SPACE_BARRIER_READ|BUS_SPACE_BARRIER_WRITE in the
bus_space_barrier() call.

So given that, I still beleive that BUS_SPACE_BARRIER_READ should
map to BUS_SPACE_BARRIER_READ_READ, and BUS_SPACE_BARRIER_WRITE
should map to BUS_SPACE_BARRIER_WRITE_WRITE.  Now the combination
of the two is a more difficult issue and probably should map to
all of the operations at once (with the possible exception of
BUS_SPACE_BARRIER_SYNC).

Eduardo