Jachym Holecek <freza@dspfpga.com> writes:

> 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?

Nope, the compiler just has to look at the spl() call and decide that
it doesn't know what that function does to globally-visible
memory. For our purposes, "an ISR could have changed the data before
the spl() call" is functionally equivalent to the spl() call changing
the data itself. As long as the compiler thinks that this is possible
- and that's exactly what the memory-clobber means - we're okay.

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

Nope, this is about convincing the compiler to do the right thing in
the top-half code. The compiler is not fundamentally aware of the
concurrency that's going on in the kernel, where interrupts can
happen; by making the spl()s have these barriers and clobbers, we're
making it treat them properly. The same issue arises with
pthread_mutex_lock() and unlock(); those work because they are
function calls. In an implementation where they are not, they would
need similar manual annotations for clobbering memory.

> 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.

It's not really about bus_dma(9)'s guarantees, which are generally at
a different layer (though they also offer useful opportunites for
barrier constructs that the compiler can respect).

        - Nathan