Thanks for looking at this! On Thu, Feb 6, 2014 at 9:33 AM, Stefan Kristiansson < stefan.kristians...@saunalahti.fi> wrote: > > Nit, s/premption/preemption >
Thanks, will fix. > I also suspect that having a larger set of operations defined in this > syscall > makes sense, even though you could use a smaller set of operation to get > the > same functionality. > Yes you can. In fact glibc only requires you to implement cmpxchg. > But, perhaps you could elaborate on the reasoning behind the larger set For example, the default implementation in glibc for 'exchange and add' (called ADD above) is basically looping an cmpxchg until the right thing happens. See https://github.com/bluecmd/or1k-glibc/blob/1688660582f50a123d38fb2298a23c5cfa4505d8/include/atomic.h It was a while ago but I'm pretty sure I implemented just the functions that relies on retries. I don't have any hard facts to support that this helps, but it feels like the sane thing to do. A bit more kernel code vs. potentially a storm of syscalls and slowness. Do you want me to include this in the comment / commit log / or just here? > The declaration of sys_or1k_atomic in arch/openrisc/include/asm/syscalls.h > should probably be updated to reflect this change as well. Agreed. Is this a good place for the operation constants? They are currently living in: https://github.com/bluecmd/or1k-glibc/blob/1688660582f50a123d38fb2298a23c5cfa4505d8/ports/sysdeps/unix/sysv/linux/or1k/nptl/bits/atomic.h Christian
_______________________________________________ Linux mailing list Linux@lists.openrisc.net http://lists.openrisc.net/listinfo/linux
