Subject: Re: bus_space and barriers
To: Nathan J. Williams <nathanw@MIT.EDU>
From: Erik E. Fair <firstname.lastname@example.org>
Date: 11/04/2000 14:43:56
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
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
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