Re: MIPS_ATOMIC_SET in sys_sysmips()

[Jun Sun <jsun@mvista.com>]

"Maciej W. Rozycki" wrote:
> 
> On Mon, 18 Dec 2000, Jun Sun wrote:
> 
> > It looks like sometime after test5 the MIPS_ATOMIC_SET case in sys_sysmips()
> > function in the CVS tree is changed.  The new code now uses ll/sc instructions
> > and handles syscall trace, etc..
> >
> > This change does not make sense to me.  The userland typically uses
> > MIPS_ATOMIC_SET when ll/sc instructions are not available.  But the new code
> > itself uses ll/sc, which pretty much forfeit the purpose.  Or do I miss
> > something else?
> 
>  There is no problem with using ll/sc in sysmips() itself for machines
> that support them.
> 

Sure - but with ll/sc available the user programs don't need to issue
sysmip(MIPS_ATOMIC_SET,...) at the first place ...

> > What do we offer to machines without ll/sc?
> 
>  I asked Ralf for a clarification of the sysmips(MIPS_ATOMIC_SET, ...)
> call before I write better code.  No response so far.  I'm now really
> cosidering implementing the Ultrix atomic_op() syscall -- at least it has
> a well-known defined behaviour.
>

Where can I find the definitino of atomic_op()?  Or can you tell us a little
more about it? 

> > BTW, what is the wrong with previous code?  I understand it may be broken in
> > SMP case, but I think that is fixable.  Comments?
> 
>  The previous code was definitely broken -- depending on the path taken it
> would return either the value fetched from memory or an error code.  No
> way to distinguish between them.
>

I notice that.  I notice glibc is the only "customer" of the MIPS_SET_ATOMIC
call, the bug does not appear to be a big deal because error should not
happen.  Of course, it will be nice to fix it.

Jun