linux-mips
[Top] [All Lists]

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

To: "Maciej W. Rozycki" <macro@ds2.pg.gda.pl>
Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Jun Sun <jsun@mvista.com>
Date: Wed, 30 May 2001 10:39:54 -0700
Cc: Ralf Baechle <ralf@uni-koblenz.de>, Joe deBlaquiere <jadb@redhat.com>, "Kevin D. Kissell" <kevink@mips.com>, linux-mips@oss.sgi.com
References: <Pine.GSO.3.96.1010530141109.9456B-100000@delta.ds2.pg.gda.pl>
Sender: owner-linux-mips@oss.sgi.com
"Maciej W. Rozycki" wrote:
> 
> On Tue, 29 May 2001, Jun Sun wrote:
> 
> > >  What about 3) -- a new syscall with a different semantics and no need to
> > > care about limitations of current implementations (especially the
> > > sysmips() bag).
> >
> > Having a new syscall is fine with me, although seems a little more 
> > instrusive
> > than adding a subcall to sysmips().
> 
>  Actually whole sysmips() looks like a crazy hack, much like ioctl(), but
> even worse (passing a pointer in an integer argument, even if it works...
> yuck!).  And it is weird, to say at least, to have different
> interpretations of the return value -- sometimes it's errno and sometimes
> it's something different.
> 

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?

Jun

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