API change for bus_dma
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
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