linux-mips
[Top] [All Lists]

Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...)

To: Jun Sun <jsun@mvista.com>
Subject: Re: linux 2.4.5: sysmips(MIPS_ATOMIC_SET) is broken (yep, again...)
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Thu, 5 Jul 2001 20:23:33 +0200 (MET DST)
Cc: Florian Lohoff <flo@rfc822.org>, Ralf Baechle <ralf@uni-koblenz.de>, linux-mips@fnet.fr, linux-mips@oss.sgi.com
In-reply-to: <3B44A91A.6AA110FC@mvista.com>
Organization: Technical University of Gdansk
Sender: owner-linux-mips@oss.sgi.com
On Thu, 5 Jul 2001, Jun Sun wrote:

> That was the conclusion, but did not make to the CVS tree, probably due to
> Ralf's unwillingness to take a overhead for "flawed" CPUs.

 What overhead?  The code is conditional at the preprocessor level.

> In my last patch for Vr41xx, I have a patch for this.  Basically, I will send
> a SIGSYS if the return value is a small negative.  This will practically
> satify all the need while keep the change minimum.  The small modification to
> the semantic is not too bad at all if you consider the original syscall
> semantic is already badly broken.

 The default action for SIGSYS is to abort with a core dump, so it seems
fine here -- I don't object.  It allows us to use the normal return path,
instead of that crude jump hack, too.

 Not that I particularly care about sysmips(MIPS_ATOMIC_SET) anymore...

  Maciej

-- 
+  Maciej W. Rozycki, Technical University of Gdansk, Poland   +
+--------------------------------------------------------------+
+        e-mail: macro@ds2.pg.gda.pl, PGP key available        +


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