[PATCH 1/6] libmm-score-api. The high-level libmm API should be used by applications. It helps developers to manage memory by setting generic and target-independent protection and cache attributes for a region that has a start address, length, and desired memory attributes.

Sebastian Huber sebastian.huber at embedded-brains.de
Tue Sep 17 07:51:55 UTC 2013

On 2013-09-14 00:05, Chris Johns wrote:
> Gedare Bloom wrote:
>>> What is the use case and benefit of this libmm?  Currently I see some
>>> low-level changes, but what is the application or kernel level use case?
>> The immediate goal would be to support POSIX mprotect on BSPs that can
>> (and to ignore it on those that don't). Other benefits may come in the
>> future, as we can consider how real-time memory protection might be
>> employed by applications.
>> Currently we do not need this high-level interface, until mprotect shows up.
> Dynamically loaded code could use it. The RTL code has support for custom
> allocators to allow code to be loaded and then configured as read-only/execute.
> There will be systems that will have requirements on loaded code being
> protected in this way.

We should first formulate the high-level requirements before we start to tinker 
with an arbitrary low-level implementation and BSP initialization changes.

If I use this mprotect() as an example we have the PROT_READ, PROT_WRITE, and 
PROT_EXEC flags.  How does this map to

+#define RTEMS_MM_REGION_BIT_READ        0
+#define RTEMS_MM_REGION_BIT_WRITE       1
+#define RTEMS_MM_REGION_BIT_CACHE       3


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.

Sebastian Huber, embedded brains GmbH

Address : Dornierstr. 4, D-82178 Puchheim, Germany
Phone   : +49 89 189 47 41-16
Fax     : +49 89 189 47 41-09
E-Mail  : sebastian.huber at embedded-brains.de
PGP     : Public key available on request.

Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.

More information about the devel mailing list