[Top] [All Lists]

Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_fro

To: "Maciej W. Rozycki" <>
Subject: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call
From: Ralf Baechle <>
Date: Sat, 27 Jan 2001 11:42:11 -0800
Cc: Joe deBlaquiere <>, Florian Lohoff <>,
In-reply-to: <>; from on Sat, Jan 27, 2001 at 08:28:05AM +0100
References: <> <>
User-agent: Mutt/1.2.5i
On Sat, Jan 27, 2001 at 08:28:05AM +0100, Maciej W. Rozycki wrote:

> > Afaik the only user of MIPS_ATOMIC_SET ever running on Linux/MIPS is the
> > Linuxthreads code you wrote, so no.  Aside of that the semantics of this
> > syscall were defined by older MIPS operating systems such as Risc/OS and
> > I think we should follow their example.
>  I still haven't seen a definite spec for the call.

Sorry, the specs is code and docs I have access to here inside SGI and which
I cannot pass on ...

>  Since you suggest the Linuxthreads code is the only user of the code
> (also remember the _test_and_set library function as specified by the ABI),
> we might abandon MIPS_ATOMIC_SET and write a _test_and_set syscall
> instead.  No compatibility issues would be involved and the definition is
> clear in the ABI (the library function would become a simple wrapper). 

We have an IRIX 5 emulation and if I remember right for IRIX 5
MIPS_ATOMIC_SET is still supported, so we need to also.  So I fear we'll
have to keep sysmips.  Which still doesn't mean we should come up with
something better.

>  I'm still uncertain if wasting a syscall number is that great idea, but
> we would be free from any compatibility problems.  And yes, I still think
> an ll/sc emulation could be done independently anyway. 


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