"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
