linux-mips
[Top] [All Lists]

Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel

To: Jun Sun <jsun@mvista.com>
Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Date: Thu, 31 May 2001 10:37:42 +0200 (MET DST)
Cc: Ralf Baechle <ralf@uni-koblenz.de>, Joe deBlaquiere <jadb@redhat.com>, "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
In-reply-to: <3B15306A.3AACAF3E@mvista.com>
Organization: Technical University of Gdansk
Reply-to: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
On Wed, 30 May 2001, Jun Sun wrote:

> Agree.  Having dual semantics for the return value is bad.
> 
> I was actually suggesting to have a new subcall in sysmips (e.g.,
> MIPS_NEW_ATOMIC_SET) and still working within the sysmips() call framework.
> 
> Is there any concern as for adding a new syscall?

 I'd prefer to avoid sysmips() (as a whole, not only the MIPS_ATOMIC_SET
subcall) for the reasons I've written previously.  There is really no
point in saving five bytes in the syscall tables just to make use of the
existing mess. 

 Note that adding MIPS_NEW_ATOMIC_SET doesn't make sysmips() more
consistent at all. 

-- 
+  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>