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

Jorge Torres jorge.torres.maldonado at gmail.com
Fri Feb 29 04:05:22 EST 2008


Hi Nelson, Damien,

Invariants about OKLinux scheduler, can be fixed, if one modifies the
scheduler to be aware of this, Nelson could your tell, where is that one
enables the IPC permission?, I think this could be achieved by some means
setting the useland linux thread as I0/Bound when waiting for IPC, therefore
it wont be scheduled by Linux, for this  one  will have to set a mechanism,
one I can think of surely not the best is, turning the thread into an
"iguana operation state" and back, this is:

Before performing L4IPC, and any other L4-iguana operations, userland linux
thread must create a waitqueue via DECLARE_WAITQUEUE(), and add itself to
such queue via add_wait_queue(), then notify an iguana's server (about this
later),  once done so, it is able to perform l4 native operations, after
done, it should notify server (back to userandlinux request),  server wakes
up the  queue,  and userland thread continues with OKlinux userland code.

What the registering iguana server should do is to:  flip-flop
OKLINUXuserland thread priority to higher or lower priority than Linux's
mian and timer threads (which is how the systems guarantees that userland
threads are always scheduled by the linux scheduler and not the L4
scheduler). For this one will have to modify the Linux set thread and eas
creation routines so it sets the scheduler register to be the server just
mentioned. this would be something like:

.
.
.
OKLINUXUserland  code
.
.
ENTER_IGUANA_STATE
.
L4-Iguana Native code
.
.
LEAVE_IGUANA_STATE
.
.
OKLINUXUserland  code


I think that would be one simple way of doing this,

Best regards,

Jorge





On Thu, Feb 28, 2008 at 2:11 AM, Nelson Tam <nelson at ok-labs.com> wrote:

> Hi Damien,
>
> On 26/02/2008, at 01:27, Damien Schulz wrote:
>
> > is it possible to have IPC directly from OKLinux userland processes
> > - no matter if it is a good idea or not? So far I've written a
> > procfs module that is able to communicate with OKL4, but I'd like to
> > directly use the IDL interface in my user processes.
> >
> > If I understand it correctly, every linux process is started as an
> > OKL4 process, so it should be possible anyway. Is there a way to
> > simply allow IPC or would that require further changes in the
> > OKLinux fork() implementation?
>
> I'm sorry about the confusion earlier.  Let me clarify a few things.
>
> What I said in the previous email about OKLinux threads being able to
> use OKL4 services holds true for OKLinux _kernel_ threads only.  There
> are 2 threads in this category - called "timer_thread" and
> "main_thread".  You can find them in kernel-2.6.10-v1/arch/l4/kernel -
> take a look in sys_iguana.c and main.c.  These 2 threads have their
> own L4 space.
>
> On the other hand, OKLinux _user_ threads runs your Linux userland
> processes in a different L4 space from the kernel threads.  The
> important thing here is that, L4 implements IPC security mechanisms on
> a per-L4-address-space basis.  While the OKLinux kernel space is given
> permission to IPC any thread in other spaces, the OKLinux user space
> is not allowed to do so.  Therefore, your OKLinux user processes won't
> be able to communicate with OKL4 services.
>
> Now you might be asking why can't you just configure the IPC
> permissions so that the OKLinux user space can IPC everyone.  The
> short answer is that, the OKLinux kernel relies on some invariants on
> when and how OKLinux user threads get scheduled.  Once you allow
> OKLinux user threads to IPC freely, these invariants get violated.
>
> I hope this answers your question.
>
> Nelson.
>
>
> _______________________________________________
> Developer mailing list
> Developer at okl4.org
> https://lists.okl4.org/mailman/listinfo/developer
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.okl4.org/pipermail/developer/attachments/20080228/4c83b275/attachment-0001.htm 


More information about the Developer mailing list