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

Linus Torvalds (torvalds@transmeta.com)
Fri, 6 Dec 2002 11:20:26 -0800 (PST)


On Fri, 6 Dec 2002, Linus Torvalds wrote:
>
> I just pushed my version of the system call restart code to the BK trees.
> It's losely based on Georges code, but subtly different. Also, I didn't
> actually update any actual system calls to use it, I just did the
> infrastructure.

I did the nanosleep() implementation using the new infrastructure now, and
am pushing it out as I write this.

Ironically (considering the origin of the thread), this actually _breaks_
the kernel/compat.c nanosleep handling, since the restarting really needs
to know the type for "struct timespec", and the common "do_nanosleep()"
was just too stupid and limited to be able to do restarting sanely.

Compat people can hopefully fix it up. Either by just copying the
nanosleep function and not even trying to share code, or by making the
restart function be a function pointer argument to a new and improved
common "do_nanosleep()".

It's been tested, and the only problem I found (which is kind of
fundamental) is that if the system call gets interrupted by a signal and
restarted, and then later returns successfully, the partial restart will
have updated the "remaining time" field to whatever was remaining when the
restart was started.

That could be fixed by making the restart block contain not just the
restart pointer, but also a "no restart possible" pointer, which would be
the one called if the signal handler logic ended up returning -EINTR.

It's a trivial extension, and possibly worth it regardless (it might be
useful for other system call cases too that may want to undo some
reservation or whatever), but I would like to hear from the standards
lawyers whether POSIX/SuS actually cares or not. George?

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/