Re: context switch vs. signal delivery [was: Re: Accelerating user mode

[Jeff Dike <jdike@karaya.com>]

us15@os.inf.tu-dresden.de said:
> If my understanding of UML is right, you implement interrupts with
> socket pairs where the interrupt handler writes a byte into one end
> and the other end receives an async notification (SIGIO). 

It sounds like you're confusing two mechanisms.  Device interrupts are 
implemented with something that supports SIGIO (socketpair, tty) with one
end outside UML and one end inside UML generating the SIGIOs.

I use socketpairs in the way you describe to implement context switching.
Out-of-context processes are sleeping in a read on their socket, and are
woken up by an soon-to-be-out-of-context process writing a byte down it.
There's no SIGIO there at all.

I also use socketpairs with SIGIO to implement IPIs on SMP UML.

> In order to
> stop the right task with a SIGIO, you change the socket owner on each
> context switch using fcntl. 

Yup.  More precisely, in order to ensure that the correct process receives
SIGIO when input comes in from the outside, I F_SETOWN the descriptors to
the incoming process during a context switch.

> If you have one process per task and a kernel process, the kernel
> process cannot change socket ownership over to the next task's
> process, because it's not allowed to.

Why not?  I see nothing at all in the implementation of F_SETOWN that requires
that it be called by the current owner:

		case F_SETOWN:
			lock_kernel();
			filp->f_owner.pid = arg;
			filp->f_owner.uid = current->uid;
			filp->f_owner.euid = current->euid;
			...

There are no general checks earlier in do_fcntl or sys_fcntl either.

				Jeff