API change for bus_dma

Scott Long scottl at freebsd.org
Sat Jun 28 09:32:16 PDT 2003

John Baldwin wrote:
> Using this approach is more flexible in case there is a driver
> that uses a sx lock or a (not yet implemented) reader-writer lock
> or a critical section, or whatever.  This just means that the
> callback uses a wrapper function but that really isn't that hard to
> do and there are other cases (callouts in general) that need this.
> To me this seems to be adding a special case to the API that won't
> work for all situations anyways.  I also don't see wrapper functions
> as being all that hard.

Ok, after many semi-private discussions, how about this:

1) New flag, BUS_DMA_INSWI, to signal that the caller is busdma_swi().
2) Remove callback_mtx and replace it with callback2, a function
pointer that wraps the callback with driver-dependent locking.  This
makes thing more flexible for alternate locking strategies.
3) Move vm_swi to be INTR_MPSAFE.  On every single arch, vm_swi
only exists to call busdma_swi().  This should not preclude other
tasks from being added to this SWI as long as appropriate locking
is done.
4) Have busdma_swi() check that callback2==NULL.  If it does,
grab Giant before calling bus_dmamap_load().  If it doesn't, call
bus_dmamap_load() with callback2 instead of the original callback.
5) bus_dmamap_load() checks BUS_DMA_INSWI==0 before overwriting
the callback and callback_args fields of the map.  It will blindly
call 'callback' and rely on the caller (either the driver or
busdma_swi) giving it the right pointer.


More information about the freebsd-arch mailing list