linux-mips
[Top] [All Lists]

Re: MIPS_ATOMIC_SET in sys_sysmips()

To: Jun Sun <jsun@mvista.com>, Ralf Baechle <ralf@uni-koblenz.de>
Subject: Re: MIPS_ATOMIC_SET in sys_sysmips()
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Tue, 19 Dec 2000 14:25:33 +0100 (MET)
Cc: linux-mips@oss.sgi.com
In-reply-to: <3A3EC1FF.9B86E2AC@mvista.com>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
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. 

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

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

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


<Prev in Thread] Current Thread [Next in Thread>