linux-mips
[Top] [All Lists]

Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Jun Sun <jsun@mvista.com>
Date: Tue, 29 May 2001 15:32:07 -0700
Cc: Ralf Baechle <ralf@uni-koblenz.de>, Joe deBlaquiere <jadb@redhat.com>, "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
References: <Pine.GSO.3.96.1010528172454.15200I-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
"Maciej W. Rozycki" wrote:
> 
> On Fri, 25 May 2001, Jun Sun wrote:
> 
> > Alright, I rolled my sleeve and digged into IRIX 6.5, and guess what?
> > sysmips() does NOT have MIPS_ATOMIC_SET (2001) on IRIX!  See the header 
> > below.
> 
>  I remember Ralf writing of this being a compatibility call with RISC/OS
> (is it the original OS of MIPS, Inc.?), IIRC.  Ralf: am I right?
> 
> > So apparently MIPS_ATOMIC_SET was invented for Linux only, probably just to
> > implement _test_and_set().  (It would be interesting to see how IRIX 
> > implement
> > _test_and_set() on MIPS I machines.  However, the machine I have access uses
> > ll/sc instructions).
> 
>  Does IRIX actually run on anything below ISA II?
>

I assume nobody answering the above questions means nobody really care.  So we
can safely move ahead without worrying about them. :-)
 
> > To me, either 1.a) or 2) is fine with me, although I have a slight faovr 
> > over
> > 2) (perhaps because I don't like assembly code and the extra "vertical"
> > calling layer introduced in 1.a)
> 
>  What about 3) -- a new syscall with a different semantics and no need to
> care about limitations of current implementations (especially the
> sysmips() bag).  

Having a new syscall is fine with me, although seems a little more instrusive
than adding a subcall to sysmips().

> I've just sent a proposal for discussion.  I'm looking
> forward for constructive feedback.
> 

The patch looks good to me.

BTW, why wouldn't you choose to have three arguments in the syscall, where the
last one is a pointer to the variable to hold the return value?  Doing that
would avoid tricky register manipulation on both calling side (fetching return
value from $v1) and kernel side (setting regs.regs[3]).

Jun

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