"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?