On 2013-09-12 08:59, Hesham AL-Matary wrote:
+/** + * @brief _Memory_management_Region Flags defs + */ + +#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 + +#define RTEMS_MM_REGION_READ (1U << RTEMS_MM_REGION_BIT_READ) +#define RTEMS_MM_REGION_WRITE (1U << RTEMS_MM_REGION_BIT_WRITE) +#define RTEMS_MM_REGION_EXECUTE (1U << RTEMS_MM_REGION_BIT_EXECUTE) +#define RTEMS_MM_REGION_CACHE (1U << RTEMS_MM_REGION_BIT_CACHE) +#define RTEMS_MM_REGION_DEVICE (1U << RTEMS_MM_REGION_BIT_DEVICE) +#define RTEMS_MM_REGION_SHARED (1U << RTEMS_MM_REGION_BIT_SHARED)
I suggested to use such a schema, but now I am no longer sure if this was a good idea.
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?
-- 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
