Personally, I think it's a brilliant idea.  Even if you'll not
be able to capture all possible scenarios this will help debug
bus space stuff a lot.

	-- Lennart

David Young wrote:
> On Thu, Feb 12, 2004 at 01:44:59PM -0500, Thor Lancelot Simon wrote:
> 
>>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?
> 
> 
> I think that for different values of "valid results," there are different
> details that need to be considered.
> 
> I can make some vague examples. For one example, if I want to study the
> effects of Alpha-like re-orderings on the reliability of Rx-interrupt
> handling in atw(4), but all I have is an i386, then I will build a kernel:
> 
>     fakebus*    at pci? dev ? function ?
>     atw*        at fakebus?
> 
> Configure Alpha-like re-orderings for register read/write:
> 
>     # fakeconfig atw0 filter \
>     > bus_space_barrier,bus_space_write_4,bus_space_read_4=alpha_reorderings
> 
> I also want to log the reads/writes:
> 
>     # fakeconfig atw0 log bus_space_write_4,bus_space_read_4
> 
> And put atw through its paces. I don't know precisely how this will all
> fit into the autoconf framework, but I am assuming in this case that a
> fakebus is a new bus type, and atw has a dev/fakebus/if_atw_fakebus.c
> that knows how to attach it.
> 
> For another example, if I want to test PCI device attachment, then I
> will configure the kernel with a fakebus that has PCI properties,
> 
>     fakepci*    at pci? dev ? function ?
>     atw*        at fakepci?
> 
> Then I will install some filter for pci_intr_map that makes it return
> an error,
> 
>     # fakeconfig atw0 filter pci_intr_map=error
> 
> I guess that I have to postpone attachment. Maybe fakebuses should attach
> their devices under control of fakeconfig....
> 
> Does this make sense so far?
> 
> Dave
>