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

[Jorge Torres]

Hi Dhiraj,

Yes, one could use L4 native calls, and non SAS based iguana services, like
high resolution timers, or driver servers (I guess),

Cheers,

Jorge



On Thu, Feb 28, 2008 at 9:58 PM, Kalamkar, Dhiraj D <
dhiraj.d.kalamkar at intel.com> wrote:

>  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/20080228/9cc38ecf/attachment-0001.htm