<p>I envision users will configure the extra protection therefore it is optional. My goal is to provide an rtems_api to protect memory regions (base, bounds, permission) that libcpu (or score/cpu) and libbsp provide the enforcement mechanism. Then higher apis can implement e.g. posix mmap protection, task stack isolation, or users can define their own protected regions. I have seb's approximate nios api and will consider it as I design the middle layer between cpukit and cpu/bsp.</p>

<p>My code will be tracked in the gsoc-mmu svn, since I am extending that code as my first cut.<br>
-gedare</p>
<div class="gmail_quote">On Oct 26, 2011 2:43 AM, "Sebastian Huber" <<a href="mailto:sebastian.huber@embedded-brains.de">sebastian.huber@embedded-brains.de</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/25/2011 10:18 PM, Joel Sherrill wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
On 10/24/2011 08:55 AM, Sebastian Huber wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
We are (at the moment) not interested in a general MPU or MMU API.  Currently<br>
we use a Nios II specific API to do the low level stuff.<br>
</blockquote>
Eventually this would result in 15+ APIs in RTEMS.  After suffering<br>
through a few IRQ APIs that were related but different, I would<br>
expect you to feel a cold chill and shudder about now.<br>
</blockquote>
<br>
We already have these 1+ APIs.  Just look at the PowerPC MMU/BAT stuff.  In the long run it is better to use one general API, but someone has to invent one.<br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
  We are interested in<br>
thread stack protection.  This means that stack overflows are detected and<br>
access to other thread stacks is prohibited.<br>
</blockquote>
<br>
Stack overflow detection is OK.<br>
<br>
Stack protection is likely to result in a violation of the POSIX<br>
process/thread model.  RTEMS is best compared to a thread<br>
implementation in a user space library in POSIX process terms.<br>
</blockquote>
<br>
Yes, it violates the POSIX thread model.  Everything has its cost.<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Obere Lagerstr. 30, D-82178 Puchheim, Germany<br>
Phone   : <a href="tel:%2B49%2089%2018%2090%2080%2079-6" value="+4989189080796" target="_blank">+49 89 18 90 80 79-6</a><br>
Fax     : <a href="tel:%2B49%2089%2018%2090%2080%2079-9" value="+4989189080799" target="_blank">+49 89 18 90 80 79-9</a><br>
E-Mail  : <a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-<u></u>brains.de</a><br>
PGP     : Public key available on request.<br>
<br>
Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.<br>
</blockquote></div>