Once it changes the system call (eax, right), could the new
call code then just get the parms from the restart_block.
Means less code for the signal handler and keeps things
simple. It also means that the call gets the orgional parms
back so it is very generic, i.e. the signal code does not
need to know which parms to change and which to not.
> So what we do is to introduce a _new_ system call
> (system call number NNN), which takes a different form of timeout, namely
> "absolute value of end time".
I think it would be best to keep this as generic as
possible, i.e. let the new call code fetch its own
paramerers from the restart_block.
>
> And then, when we enter do_signal(), we not only update %eip to point to
> the original "int 0x80" instruction, we _also_ update %eax to point to the
> new system call NNN, _and_ we update %ebx to contain the new timeout in
> absolute jiffies:
>
> current_thread->restart_block.syscall_nr = NNN;
> current_thread->restart_block.arg0 = jiffies + timeout;
My question is who sets up these values? I think you are
saying it should be the system call. Is this right?
>
> and then we have a
>
> sys_nanosleep_resume(unsigned long timeout, struct timespec *rem)
> {
> long jif = timeout - jiffies;
>
> if (jif > 0) {
> current->state = TASK_INTERRUPTIBLE;
> jif = schedule_timeout(jif);
> /* interrupted - we already have the restart block set up */
> if (jif) {
> if (rem)
> jiffies_to_usertimespec(jif, rem);
> return -ERESTART_RESTARTBLOCK;
> }
> }
> put_user(0, rem->tv_sec);
> put_user(0, rem->tv_nsec);
> return 0;
> }
>
> See? The "nanosleep_resume" system call is never used by a program
> directly, it's only virtualized by the signal restart changing the system
> call number on restart. (A user program _could_ use it directly, but
> there's no point, and the interface to the thing might change at any
> time).
I think we could cause it to error out, if, for example, the
restart_block is null.
-- George Anzinger george@mvista.com High-res-timers: http://sourceforge.net/projects/high-res-timers/ Preemption patch: http://www.kernel.org/pub/linux/kernel/people/rml - 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/