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.

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. 

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?)