On Sun, Feb 08, 2004 at 08:09:43PM -0600, David Young wrote:
> 
> 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.

I can see how we could use bus_space or even, under limited conditions,
bus_dma to do this.  I am skeptical about the applicability to
interrupt-driven and DMA device or driver operation, though.  It seems
like for device simulation, you'd end up with some hack to call the
driver's interrupt routine after manipulating the I/O that ultimately
lost the timing of the underlying events -- this would even be true
with just a reordering bus, unless you carefully imposed a uniform delay
on all operations.  That seems likely to hide ugly corner cases in drivers,
or distort performance analyses.  In the DMA case, it'd be important to
interpose a "DMA reorderer" that actually obeyed the same physical
constraints as the device itself, with regard to alignment, etc. and
possibly to know something about the actual bus hardware the device was
physically attached through.

I know these seem like nitpicking details, but I think there are a _lot_ 
of such details to be considered before arriving at a general framework
that could simulate devices or buses, or be interposed between real ones,
with valid results.  What's your take on this?

Thor