<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Tue, Sep 17, 2013 at 9:51 AM, Sebastian Huber <span dir="ltr"><<a href="mailto:sebastian.huber@embedded-brains.de" target="_blank">sebastian.huber@embedded-brains.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><div class="im">On 2013-09-14 00:05, Chris Johns wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
Gedare Bloom wrote:<br>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
What is the use case and benefit of this libmm? Currently I see some<br>
low-level changes, but what is the application or kernel level use case?<br>
<br>
</blockquote>
The immediate goal would be to support POSIX mprotect on BSPs that can<br>
(and to ignore it on those that don't). Other benefits may come in the<br>
future, as we can consider how real-time memory protection might be<br>
employed by applications.<br>
<br>
Currently we do not need this high-level interface, until mprotect shows up.<br>
<br>
</blockquote>
<br>
Dynamically loaded code could use it. The RTL code has support for custom<br>
allocators to allow code to be loaded and then configured as read-only/execute.<br>
There will be systems that will have requirements on loaded code being<br>
protected in this way.<br>
</blockquote>
<br></div>
We should first formulate the high-level requirements before we start to tinker with an arbitrary low-level implementation and BSP initialization changes.<br>
<br>
If I use this mprotect() as an example we have the PROT_READ, PROT_WRITE, and PROT_EXEC flags. How does this map to<div class="im"><br>
<br>
+#define RTEMS_MM_REGION_BIT_READ 0<br>
+#define RTEMS_MM_REGION_BIT_WRITE 1<br>
+#define RTEMS_MM_REGION_BIT_EXECUTE 2<br>
+#define RTEMS_MM_REGION_BIT_CACHE 3<br>
+#define RTEMS_MM_REGION_BIT_DEVICE 4<br>
+#define RTEMS_MM_REGION_BIT_SHARED 5<br>
<br></div>
?<br></blockquote><div>I agree with you that these macros are not useful at high-level layer,</div><div>currently they are used only at low-level/BSP mm.c file, so I will move it to BSP</div><div>layer to help in translating high-level attributes to CPU specific ones.</div>
<div><br></div><div>This is an initial implementation [1] of mprotect not included in these patches.</div><div>Also, we (I and Gedare) agreed to delay this high-level layer patch</div><div>until we implement mprotect as a use-case.</div>
<div> </div><div>[1] <a href="https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/posix/src/mprotect.c">https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/posix/src/mprotect.c</a></div>
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
<br>
I suggested to use such a scheme since I had only the BSP low-level stuff in mind. For a mprotect() support this is not a good approach. Here it makes more sense to specify high-level region properties and use an architecture provided mapping to low-level MMU bits. I think this was the original proposal by Hesham Moustafa.<div class="im">
<br>
<br>
-- <br>
Sebastian Huber, embedded brains GmbH<br>
<br>
Address : Dornierstr. 4, D-82178 Puchheim, Germany<br>
Phone : +49 89 189 47 41-16<br>
Fax : +49 89 189 47 41-09<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></div><div class=""><div class="h5">
______________________________<u></u>_________________<br>
rtems-devel mailing list<br>
<a href="mailto:rtems-devel@rtems.org" target="_blank">rtems-devel@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-devel" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-devel</a><br>
</div></div></blockquote></div><br></div></div>