# Nathan J. Williams 2007-04-26:
> Jachym Holecek <freza@dspfpga.com> writes:
> >> workaround for a deficient spl() implementation.
> >
> > How could be spl() implemented to avoid the need for volatiles?
> 
> As Jason mentioned, by making sure that they are both instruction
> barriers and memory clobbers. Ordinary function calls satisfy this
> constrtaint; macros and inline functions generally do not.
> 
> If you have those condtitions on your spl calls, and structure the
> code so that the top half looks like:
> 
> .. 
> s = splfoo()
> <work with memory region>
> splx(s)
> ..
> 
> where it doesn't touch the memory region outside of the
> spl()-protected block,

Aha, I was missing this (key) piece of the picture. Thank you & Jason
for explanation.

> then the compiler has enough information to know that the contents of
> memory region A could change between one spl-protected block and another,
> but that it won't change within the block.

This implies the ISR itself will have spl() calls -- this would seem
to imply hard-ISRs will become cheap stubs scheduling the real work
into thread context?

Hmm, or the hard-ISR can just do insn barrier & memory clobber manually
wherever it touches "shared" memory region.

Back to the topic -- I can see two options for the new USB code:

  1. Respect bus_dma(9)'s current definition and put back the volatiles.

  2. Redefine bus_dmamap_sync(9) to imply "also does what volatile
     would do". This includes changes to some bus_dma(9) backends.

In other words, I'd expect the code (as-is) to break on some arches.

	-- Jachym