Re: [PATCH] compatibility syscall layer (lets try again)

Linus Torvalds (torvalds@transmeta.com)
Mon, 9 Dec 2002 09:33:22 -0800 (PST)


On Mon, 9 Dec 2002, Martin Schwidefsky wrote:
>
> For s390/s390x this is actually quite tricky. The system call number is
> coded in the instruction, e.g. 0x0aa2 is svc 162 or sys_nanosleep. There
> is no register involved that contains the system call number I could
> simply change. I either have to change the instruction (no way) or I
> have to avoid going back to userspace in this case. This would require
> assembler magic in entry.S. Not nice.

Well, that is tricky independently of the actual argument stuff - even the
_current_ system call restart ends up being tricky for you in that case, I
suspect. The current one already basically depends on rewriting the system
call number, it just leaves the arguments untouched.

One thing you could do (which is pretty much architecture-independent) is
to have a "restart" flag in the thread info structure. The system call
entry code-path already has to check the thread info structure for things
like the "ptrace" flags, so it shouldn't add much overhead to the system
call entrypoint.

You would need to add a "do _not_ restart" macro to the system call
restart infrastructure, which would clear the restart bit when a restarted
system call returns (it also would get cleared when ERESTART_RESTARTBLOCK
ends up being changed into an EINTR, of course, but that's already
architecture-dependent code so you can do anything there).

Linus

-
To unsubscribe from this list: send the line "unsubscribe linux-kernel" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Please read the FAQ at http://www.tux.org/lkml/