On Tue, Sep 17, 2013 at 9:51 AM, Sebastian Huber < sebastian.hu...@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@embedded-**brains.de<sebastian.hu...@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@rtems.org > http://www.rtems.org/mailman/**listinfo/rtems-devel<http://www.rtems.org/mailman/listinfo/rtems-devel> >
_______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
