linux-mips
[Top] [All Lists]

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

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call
From: Ralf Baechle <ralf@oss.sgi.com>
Date: Fri, 26 Jan 2001 13:15:03 -0800
Cc: Joe deBlaquiere <jadb@redhat.com>, Florian Lohoff <flo@rfc822.org>, linux-mips@oss.sgi.com
In-reply-to: <Pine.GSO.3.96.1010126111156.8903B-100000@delta.ds2.pg.gda.pl>; from macro@ds2.pg.gda.pl on Fri, Jan 26, 2001 at 11:21:43AM +0100
References: <3A70CA98.102@redhat.com> <Pine.GSO.3.96.1010126111156.8903B-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
User-agent: Mutt/1.2.5i
On Fri, Jan 26, 2001 at 11:21:43AM +0100, Maciej W. Rozycki wrote:

>  Ralf, BTW, what do you think if we send a segfault on a memory access
> violation instead of returning an error?  That would make the behaviour of
> MIPS_ATMIC_SET consistent for any memory contents.  Does anything actually
> rely on the function to return an error in such a situation? 

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.

  Ralf

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