This is a good point.  I think Manuel's take on this is that the 
platform code should be aware of this and do the "right" thing.  (I.e. 
insert whatever code is necessary to force the ordering.)

I think this would be efficient and not a concern in any case.  My 
concern was for those platforms (again, mainly MIPS because that's what 
I'm working on) where the barrier is inplemented as a global cache flush.

Now I had not considered whether any MIPS parts would reorder memory 
accesses -- I don't think they do, otherwise things would be horribly 
busted today, based upon what Manuel has already said (namely that many 
drivers assume implicit barriers/ordering.)

    -- Garrett

Wolfgang Solfrank wrote:

> Hi,
>
> Sorry, I didn't follow this discussion closely enough, but it sounds
> as if you guys are assuming that accessing hardware uncached would make
> barriers superfluous.  E.g.:
>
>>> Concrete example: wi(4) on mips.  Currently these just "work" 
>>> because the PCI space is mapped uncached.  But the barrier ops for 
>>> that platform issues a cache flush.
>>
>
> The above is _not_ valid in all cases.  E.g. on PowerPC, the cpu will 
> reorder
> bus cycles even to uncached regions of its bus space.  You have to 
> explicitly
> use barrier instructions to forbid reordering across these borders.
>
> Hope it helps.  However, just ignore this mail if you are aware of this.
>
> Ciao,
> Wolfgang