Subject: Re: Enhancements to bus_space_barrier
To: None <firstname.lastname@example.org, jonathan@DSG.Stanford.EDU>
From: None <email@example.com>
Date: 10/19/2001 23:24:54
| In message <firstname.lastname@example.org>email@example.com 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
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