A couple of observations on this discussion.

1. memory barriers only matter on heavily pipelined processors (i.e. 
modern stuff), but we run on all kinds of hardware. Not every driver 
will need memory barriers; depends on whether it runs on modern stuff 
or not. Argueably, adding the barrier stuff in when you know you're 
never going to need it is going to make the drivers harder to read 
and maintain.

2. this is being presented as a dichotomy; barriers explicit or 
implict, when they are required. There is no reason why we can't have 
both, provided the APIs are clearly delineated, differentiated, and 
documented.

3. having both an explicit memory barrier API and an implicit memory 
barrier API allows us to have the best both worlds: less than 
completely wizardly programmers who can get a device working with the 
implicit API, and wizardly programmers who can make the device 
perform to its limits with the explicit API.

We have a strong desire to "get it right the first time" in the 
NetBSD community, but this ethic has gotten us into trouble time and 
again. If we allow for stepwise, incremental refinement, we converge 
on the nearly perfect implementation over time, while making visible 
progress along the way. The key is to keep iterating over the code 
(turning the crank on the process) so that we don't get stuck at a 
sub-optimal level.

	Erik <fair@clock.org>