Hi Geoff,<br><br>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:<br><br><div class="gmail_quote"><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<div class="Ih2E3d"><br>
</div>It is up to the system to prevent such abuse by user threads in<br>
preemptive multi-tasking environments. Modules are different because<br>
they run with the same privileges as the Linux kernel anyway, this is<br>
not the case for user applications.</blockquote><div> </div><div class="Ih2E3d">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. <br>
<br>
</div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">This does not work because it can allow the "current" pointer<br>
in Linux to get stale. e.g. Thread A runs, gets interrupted due<br>
to an OK Linux timer interrupt, OK Linux performs scheduling decision +<br>
dispatch and hence changes the current pointer. At this point<br>
the L4 timeslice expiry kicks in, the scheduler schedules Thread A<br>
due to robin-robin scheduling and at this point your current pointer<br>
is stale.</blockquote><div> </div><div>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).<br>
<br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Unfortunately this scheme does not work as pointed out above.<br>
<br>
Note that currently the system does not enforce who the OK Linux<br>
user threads can Ipc() to. What we are trying to say is you<br>
can in theory use Ipc() inside OK Linux user threads, however, there<br>
are many things that need to be considered if you dec</blockquote><div> </div><div>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.<br>
<br>Cheers AGAIN,<br><br><br>JORGE<br><br></div><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
><br>
><br>
> Cheers,<br>
><br>
> Jorge<br>
<font color="#888888"><br>
-gl<br>
</font><div><div></div><div class="Wj3C7c"><br>
><br>
> On Fri, Feb 29, 2008 at 12:49 AM, Nelson Tam <<a href="mailto:nelson@ok-labs.com">nelson@ok-labs.com</a>> wrote:<br>
><br>
> > Hi all,<br>
> ><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>
> > 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>
> > 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>
> > (nt)<br>
> ><br>
> > Nelson Tam<br>
> > <a href="mailto:nelson@ok-labs.com">nelson@ok-labs.com</a><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > Developer mailing list<br>
> > <a href="mailto:Developer@okl4.org">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>
> ><br>
<br>
> _______________________________________________<br>
> Developer mailing list<br>
> <a href="mailto:Developer@okl4.org">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>
<br>
<br>
</div></div>--<br>
<br>
</blockquote></div><br>