[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.

[Hesham Moustafa]

On Tue, Sep 17, 2013 at 9:51 AM, Sebastian Huber <
sebastian.huber at embedded-brains.de> wrote:

> 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_EXECUTE     2
> +#define RTEMS_MM_REGION_BIT_CACHE       3
> +#define RTEMS_MM_REGION_BIT_DEVICE      4
> +#define RTEMS_MM_REGION_BIT_SHARED      5
>
> ?
>
I agree with you that these macros are not useful at high-level layer,
currently they are used only at low-level/BSP mm.c file, so I will move it
to BSP
layer to help in translating high-level attributes to CPU specific ones.

This is an initial implementation [1]  of mprotect not included in these
patches.
Also, we (I and Gedare) agreed to delay this high-level layer patch
until we implement mprotect as a use-case.

[1]
https://github.com/heshamelmatary/rtems-gsoc2013/blob/low-level-libmm/cpukit/posix/src/mprotect.c

>
> 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<sebastian.huber at embedded-brains.de>
> PGP     : Public key available on request.
>
> Diese Nachricht ist keine geschäftliche Mitteilung im Sinne des EHUG.
> ______________________________**_________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/devel/attachments/20130917/75738f02/attachment.html>