Subject: Re: Enhancements to bus_space_barrier
To: None <, jonathan@DSG.Stanford.EDU>
From: None <>
List: tech-kern
Date: 10/19/2001 23:24:54
| In message <> 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() call.

So given that, I still beleive that BUS_SPACE_BARRIER_READ should
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