[Top] [All Lists]

Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: Jun Sun <>
Subject: Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: "Maciej W. Rozycki" <>
Date: Wed, 23 May 2001 15:18:39 +0200 (MET DST)
Cc: Florian Lohoff <>,, Pete Popov <>, George Gensure <>,
In-reply-to: <>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <>
On Tue, 22 May 2001, Jun Sun wrote:

> I took a look of MIPS ABI in system V and found that the spec only specifies
> this extended call in C prototype:
> int _test_and_set(int *p, int v);
> It seems perfectly legal for us to add one more argument to store the return
> value while still have the function returns error.  Of course, doing that will
> break binary compatibility.

 We have _test_and_set() in the library.  Implementing a clean underlying
_test_and_set() syscall is very high on my to-do list -- lack of time
prevents me from finishing it, unfortunately.

 There is no point to mess with sysmips() any further, I think.  The
library's _test_and_set() only calls sysmips() if the library was compiled
for ISA I systems.  As I guess from reports on the list, ISA I systems are
a minority, mostly DECstations and possibly a few embedded systems.  Most
people have ISA II+ and they do not need to call any syscall from
_test_and_set() at all.  For ISA II+ systems the library implements
_test_and_set() in the userland, using ll/sc appropriately. 

 Anyone having ISA II+ systems only, please do yourself a favour and set
"-mips2" (or maybe even "-mips3") somewhere in your CFLAGS for all
compilations -- not only you'll get better optimized binaries, but you'll
get rid of this sysmips() problem as well. 

> Otherwise, I think Flo's patch is the best fix to satisfy the spec and binary
> compatibility although it is a little clunky.

 I'll have yet to look at the patch, but what I think is, we should get
sysmips() work as defined by the original spec (or as reverse-engineered,
as the real spec seems to be out of reach).  Everything else belong to a
separate implementation. 

 Binary compatibility is not a necessity here.  The only sysmips() client
is glibc at the moment, and it can be updated to use a new syscall at any

 In short: let's leave sysmips() semantics alone.

+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+        e-mail:, PGP key available        +

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