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

[Jorge Torres]

Hi Geoff,

Thanks for your reply, but I'm not sure if you've read the previous e-mails
on this, this is due to the following, and please forgive me if I'm wrong:


> It is up to the system to prevent such abuse by user threads in
> preemptive multi-tasking environments.  Modules are different because
> they run with the same privileges as the Linux kernel anyway, this is
> not the case for user applications.


Yes, but we are talking of enabling IPC communication between oklinux user
threads and l4 native ones, true; the usual way of doing this is by writing
a proxy driver that does it, My point is that writing such driver is still
dangerous, just as it is enabling direct IPC on the basis of giving the
OKLInux user thread a higher priority than the OKLinuxkernel one, and making
the oklinux scheduler aware of it, by the mechanism initially proposed in
this discussion.

This does not work because it can allow the "current" pointer
> in Linux to get stale.  e.g. Thread A runs, gets interrupted due
> to an OK Linux timer interrupt, OK Linux performs scheduling decision +
> dispatch and hence changes the current pointer.  At this point
> the L4 timeslice expiry kicks in, the scheduler schedules Thread A
> due to robin-robin scheduling and at this point your current pointer
> is stale.


This wont happen since as initially pointed linux scheduler would've been
aware of it, and hence would've have sent it to a waitqueue, before the
userlevel threads enters into dealing with native l4-iguana operations
(please refer to the first emails on this). therefore linux kernel will
never perform as you say, as long as the thread remains on the waitqueue as
proposed (making the scheduler aware of threads performing l4native
aperations).


> Unfortunately this scheme does not work as pointed out above.
>
> Note that currently the system does not enforce who the OK Linux
> user threads can Ipc() to.  What we are trying to say is you
> can in theory use Ipc() inside OK Linux user threads, however, there
> are many things that need to be considered if you dec


This is just a propossal for Damien's idea,  on  direct IPCing,  nothing
else, on which I have proposed that it could be possible if the scheduler
knows that it can't schedule tasks that are doing l4 IPCing.

Cheers AGAIN,


JORGE

>
> >
> > Cheers,
> >
> > Jorge
>
>        -gl
>
> >
> > 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
> > >
>
> > _______________________________________________
> > 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/20080303/77314168/attachment-0001.htm