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

[Kalamkar, Dhiraj D]

Hi Jorge,

 

I am not sure whether OKLinux userland process can access Iguana
services directly even after the changes you suggested in OKLinux
scheduler. As far as I understand Iguana server and other services are
based on Iguana Single Address Space (SAS). i.e. Iguana server and other
services work on assumption that they have same virtual to physical
mappings for all the threads in Iguana PD (of course with different
access rights). As OKLinux user processes are external address spaces
(EAS) they can not access iguana services directly.

 

Of course, after enabling IPC for userland OKLinux process, you can do a
raw IPC to any L4 thread and may write services which don't assume
Iguana SAS.

 

Please correct me if my understanding is wrong.

 

Regards,

Dhiraj

 

________________________________

From: developer-bounces at okl4.org [mailto:developer-bounces at okl4.org] On
Behalf Of Jorge Torres
Sent: Thursday, February 28, 2008 10:35 PM
To: Nelson Tam; developer
Subject: Re: [okl4-developer] Direct IPC from OKLinux userland processes
toOKL4 services

 

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/20080229/1a3d304b/attachment.htm