[ Ewww, mailserver breakage -- sorry if you see this more than once. ]

# Nathan J. Williams 2007-04-26:
> Jachym Holecek <freza@dspfpga.com> writes:
> [... more insight on barriers ...]

OK, understood. Thanks again.

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

IIRC the idea behind volatile removal in USB code was that _sync()
implies memory barrier -- which is not the case b/c any bus_dma(9)
operation is explicitely allowed to be implemented as a macro (and
actually can evaluate to "(void)0" on some arches), ie. not function
call with its implications.

[ My only point is that reworked USB stack will have problems at
  least on some architectures, AFAICS. ]

	-- Jachym