Hi Nelson,<br><br>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,<br>
<br>
1. For starters, OKLinux user threads will be able to starve the<br>
OKLinux kernel and other user threads if they make continual calls to<br>
OKL4 services.<br><br>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.<br><br>
2. The OKLinux kernel threads act as user threads' pagers. If a<br>
pagefault occurs during the RPC, you'll find that the pager is running<br>
on a lower priority than the thread it's trying to service. That's<br>
technically ok, but could lead to funny and interesting (read: weird<br>
and undefined) behaviour.<br><br>What if not a higher priority but the same one instead?<br><br><br>
3. Who is going to increase the user thread's priority when an RPC<br>
occurs? You can't trust the user thread itself to do it, and the L4<br>
security model forbids it anyway. The RPC server could do it, but<br>
that would introduce a race condition during the RPC transfer.<br><br>True, but giving the thread the same priority the kernel has would do fine, and will fix starvation risk, doesn't it?<br><br><br>Cheers,<br><br>Jorge<br>
<br><div class="gmail_quote">On Fri, Feb 29, 2008 at 12:49 AM, Nelson Tam <<a href="mailto:nelson@ok-labs.com" target="_blank">nelson@ok-labs.com</a>> wrote:<br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Hi all,<br>
<div><br>
On 29/02/2008, at 1:58 PM, Kalamkar, Dhiraj D wrote:<br>
<br>
> I am not sure whether OKLinux userland process can access Iguana<br>
> services directly even after the changes you suggested in OKLinux<br>
> scheduler. As far as I understand Iguana server and other services<br>
> are based on Iguana Single Address Space (SAS). i.e. Iguana server<br>
> and other services work on assumption that they have same virtual to<br>
> physical mappings for all the threads in Iguana PD (of course with<br>
> different access rights). As OKLinux user processes are external<br>
> address spaces (EAS) they can not access iguana services directly.<br>
><br>
> Of course, after enabling IPC for userland OKLinux process, you can<br>
> do a raw IPC to any L4 thread and may write services which don't<br>
> assume Iguana SAS.<br>
<br>
<br>
</div><div>On 29/02/2008, at 2:12 PM, Jorge Torres wrote:<br>
<br>
> Yes, one could use L4 native calls, and non SAS based iguana<br>
> services, like high resolution timers, or driver servers (I guess),<br>
<br>
<br>
</div>Not all OKL4 services rely on the SAS. As correctly noted, as long as<br>
the service doesn't require any sort of shared memory, EAS threads<br>
would be able to utilise them also.<br>
<br>
Which brings me to an earlier question asked by Jorge: how to control<br>
IPC permissions in L4? The answer is L4_SecurityControl() (for IPC<br>
permissions you probably want the wrappers L4_IpcAllow() and cousins).<br>
<br>
But as I said before, you shouldn't do this in the OKLinux setup due<br>
to scheduling reasons.<br>
--<br>
<font color="#888888">(nt)<br>
</font><div><br>
Nelson Tam<br>
<a href="mailto:nelson@ok-labs.com" target="_blank">nelson@ok-labs.com</a><br>
<br>
<br>
</div><div><div></div><div>_______________________________________________<br>
Developer mailing list<br>
<a href="mailto:Developer@okl4.org" target="_blank">Developer@okl4.org</a><br>
<a href="https://lists.okl4.org/mailman/listinfo/developer" target="_blank">https://lists.okl4.org/mailman/listinfo/developer</a><br>
</div></div></blockquote></div><br>