| 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 + |
| Previous by Date: | Re: MIPS_ATOMIC_SET again (Re: newest kernel, Maciej W. Rozycki |
|---|---|
| Next by Date: | Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel, Ralf Baechle |
| Previous by Thread: | Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel, Jun Sun |
| Next by Thread: | Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel, Ralf Baechle |
| Indexes: | [Date] [Thread] [Top] [All Lists] |