Subject: testing bus barriers
To: None <tech-kern@netbsd.org>
From: David Young <dyoung@pobox.com>
List: tech-kern
Date: 02/08/2004 20:09:43
One night I put all the explicit bus barriers into wi(4). Afterward I
realized that there is no architecture whose every bus_space_{read,write}*
method does not contain an implicit read/write barrier.

As long as we have to change to explicit barriers globally, I don't see
NetBSD getting it done.  Would it be possible or useful to switch off
the implicit bus barriers on a per-driver basis?  Then programmers would
be able to add and test barriers in all their drivers on real hardware,
and see the difference.

A word about testing bus barriers: I keep coming back to this idea
of producing a "virtual bus" which either simulates a bus or else
filters/logs/re-orders I/O before passing it through to a physical bus.
An overlay bus that re-orders I/O under the constraints set by explicit
bus barriers would be useful for stressing a device driver to find bugs
in the placement of barriers. An overlay bus could reverse I/O, say,
or randomize it, whenever barriers did not forbid it.

(Another use of virtual buses is device simulation. With a virtual bus,
one can simulate some subset of a device's register set, or else simulate
an ethernet NIC's descriptor rings, et cetera, in order to test the
units of a device driver.)

Thoughts?

Dave

-- 
David Young             OJC Technologies
dyoung@ojctech.com      Urbana, IL * (217) 278-3933