[Top] [All Lists]

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

To: "Maciej W. Rozycki" <>
Subject: Re: Surprise! (Re: MIPS_ATOMIC_SET again (Re: newest kernel
From: Jun Sun <>
Date: Wed, 30 May 2001 10:39:54 -0700
Cc: Ralf Baechle <>, Joe deBlaquiere <>, "Kevin D. Kissell" <>,
References: <>
"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?


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