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

[Jorge Torres]

Hi Nelson,

Please forgive my stubornes, It is clear to me that the best thing is to
have a driver that proxies IPC messages to OKLINUXuser  applications, but I
see  oklinux threads direct IPC to others, a useful "out of the box-plug and
play" feature, as stated before this proposal is  way far from the best, but
regarding to the problems you mention, I believe can still be fixed,

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.

Yes very true, It is on developer hands to prevent this, but a similar or
worse risk exists if the linux driver is not well developed.

  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.

What if not a higher priority but the same one instead?


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.

True, but giving the thread the same priority the kernel has would do fine,
and will fix starvation risk, doesn't it?


Cheers,

Jorge

On Fri, Feb 29, 2008 at 12:49 AM, Nelson Tam <nelson at ok-labs.com> wrote:

> Hi all,
>
> On 29/02/2008, at 1:58 PM, Kalamkar, Dhiraj D wrote:
>
> > 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.
>
>
> On 29/02/2008, at 2:12 PM, Jorge Torres wrote:
>
> > Yes, one could use L4 native calls, and non SAS based iguana
> > services, like high resolution timers, or driver servers (I guess),
>
>
> Not all OKL4 services rely on the SAS.  As correctly noted, as long as
> the service doesn't require any sort of shared memory, EAS threads
> would be able to utilise them also.
>
> Which brings me to an earlier question asked by Jorge: how to control
> IPC permissions in L4?  The answer is L4_SecurityControl() (for IPC
> permissions you probably want the wrappers L4_IpcAllow() and cousins).
>
> But as I said before, you shouldn't do this in the OKLinux setup due
> to scheduling reasons.
> --
> (nt)
>
> Nelson Tam
> nelson at ok-labs.com
>
>
> _______________________________________________
> 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/20080302/f20aa386/attachment.htm