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