On Wed, 23 May 2001, Jun Sun wrote:
> Same old questions : Where is the definition of sysmips()? What is considered
> standard implementation of sysmips() so that we can do reverse-engineering?
> Irix?
I think Ralf can comment it.
> Even if Irix is considered standard implementation of sysmips(), I wonder if
> we need to mirror it. Here is my reasoning.
>
> The sytem V ABI specifies _test_and_set() as the exntended system call.
I think we want to execute IRIX binaries. The idea of providing
sysmips() was to provide compatibility to other systems, AFAIK. I reused
sysmips() for pthreads support in glibc as it was non-existent for ISA I
CPUs and I needeed librt to run on my R3k.
Much of discussion happened later and the conclusion was it's better to
make a new call than to try to fiddle with sysmips(). I was not aware of
the problems with sysmips() when I wrote the glibc code as sysmips() was
nowhere defined and the interface seemed to be reasonable as implemented
at that time. Later I was told sysmips(MIPS_ATOMIC_SET) is expected to
return an error code which makes it incompatible to _test_and_set().
> Therefore, for MIPS I system, we simply choose to call sysmips(NEW_ATOMIC_SET,
> ....) with three arguments. Any application that bypasses _test_and_set() and
> calls sysmips() directly is running at its own risk of not being portable.
Well, I now see using sysmips() for this purpose is ugly, it complicates
immplementation a lot and hits performance of these slow systems where we
want to save as many CPU cycles as possible. And still the problem of the
error code remains.
> Of course, we need to fix glibc, which seems to be the only client that
> matters at this moment.
That is not a problem, as I already stated. I'll see if I can cook the
new syscall I'm writing of, soon. You'll see what I mean, then.
> In short, I think we DON"T have to maitain the semantic of sysmips(). My
> understanding is that it is justed used to implement extended MIPS ABS calls.
Adding a new subfunction of sysmips() is not a problem. The cleanness on
the code and the performance is. Note that other subfunctions of
sysmips() are not performance-critical.
The whole idea of sysmips() appears hackish to me.
Maciej
--
+ Maciej W. Rozycki, Technical University of Gdansk, Poland +
+--------------------------------------------------------------+
+ e-mail: macro@ds2.pg.gda.pl, PGP key available +
|