Andrew Doran wrote:
On Wed, Jan 14, 2009 at 07:55:09PM +0100, Jean-Yves Migeon wrote: membar_foo() are for memory barriers in a multiprocessor system. The fence functions are used for memory barriers in respect of DMA even on a uniprocessor system,
AlrightWell, considering the x86 memory model, I guess it is very tolerant, and I got lucky during my build.sh run then.
For my personal culture, any way to stress or trigger a race in such a case?
or in a system like Xen where the NetBSD kernel is uniprocessor but the monitor can be on a different CPU.
Hmm, I do not understand this one. Under Xen, even for a UP domain, we do not alter the membar_ops() primitives, they keep their MP definition (there is no call to x86_patch() that patches the lock prefixes, for example).
Why should the fences be any different than their membar_ops(3) equivalent here? In Xen drivers, there is no DMA, we are just bouncing data back and forth through shared pages. From my PoV, the membar_ops do make sense in this case as synchronisation primitives.
[1] http://www.netbsd.org/~jym/membar_ops.diffThis should not be committed as is. Thanks,
What should I do? Drop it for the x86 generic bus code, and keep it for the Xen drivers?
Many thanks for all who responded. Cheers, -- Jean-Yves Migeon jeanyves.migeon%free.fr@localhost