| 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 |
| Previous by Date: | Re: Cross compiling RPMs, Mike McDonald |
|---|---|
| Next by Date: | Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call, Ralf Baechle |
| Previous by Thread: | Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call, Maciej W. Rozycki |
| Next by Thread: | Re: [FIX] sysmips(MIPS_ATMIC_SET, ...) ret_from_sys_call vs. o32_ret_from_sys_call, Maciej W. Rozycki |
| Indexes: | [Date] [Thread] [Top] [All Lists] |