[okl4-developer] Direct IPC from OKLinux userland processes to OKL4 services

[Nelson Tam]

Hi Jorge,

Thanks for your previous email.  I was in the middle of replying when  
I got your second mail :)

On 29/02/2008, at 2:00 PM, Jorge Torres wrote:

> This is in order to correct my last e-mail, since now that I read;  
> it isn't a bit clear:
>
> I think that dealing with OKLinux scheduler invariants is possible,  
> if we avoid a thread performing L4 native calls being scheduled by  
> OKLinux, this could happen if we send such thread to a waitqueue,  
> and set its priority to be higher than the main and timer (oklinux)  
> threads, once the thread is done performing as l4 native, it should  
> be taken out of the waitqueue, and its priority should be set to the  
> one it had initialy.


There are several problems with the proposal:

1. For starters, OKLinux user threads will be able to starve the  
OKLinux kernel and other user threads if they make continual calls to  
OKL4 services.

2. The OKLinux kernel threads act as user threads' pagers.  If a  
pagefault occurs during the RPC, you'll find that the pager is running  
on a lower priority than the thread it's trying to service.  That's  
technically ok, but could lead to funny and interesting (read: weird  
and undefined) behaviour.

3. Who is going to increase the user thread's priority when an RPC  
occurs?  You can't trust the user thread itself to do it, and the L4  
security model forbids it anyway.  The RPC server could do it, but  
that would introduce a race condition during the RPC transfer.

A simple and safe way of achieving the same purpose, for now, would be  
asking OKLinux server threads to make the RPC request on behalf of the  
user threads.

--
(nt)

Nelson Tam
nelson at ok-labs.com