On Mon, Aug 26, 2013 at 2:15 PM, Hesham Moustafa <heshamelmat...@gmail.com> wrote: > > > > On Mon, Aug 26, 2013 at 5:22 PM, Sebastian Huber > <sebastian.hu...@embedded-brains.de> wrote: >> >> On 2013-08-26 02:14, Hesham AL-Matary wrote: >>> >>> +/** >>> + * @brief _Memory_management_Region Flags defs >>> + */ >>> +#define RTEMS_MM_REGION_NO_PROTECTION 0x0 >>> +#define RTEMS_MM_REGION_PROTECTION_READ_ONLY 0x1 >>> +#define RTEMS_MM_REGION_PROTECTION_WRITE 0x2 >>> +#define RTEMS_MM_REGION_NO_ACCESS 0x3 >>> +//#define RTEMS_MM_REGION_PROTECTION_EXEC 0x4 >> >> >> I prefer to actually have flags here and not a single integer value. >> >> So I would use this: >> >> #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 >> > Some of these flags are not supported on some architectures like > RTEMS_MM_REGION_BIT_SHARED, or targets that do not have > Cache Unit. How should we handle some of these flags for such > targets that do not support these features in hardware ? I would think the BSP will have to handle / ignore the attributes that do not make sense for it?
>> >> #define RTEMS_MM_REGION_READ (1U << RTEMS_MM_REGION_BIT_WRITE) >> etc. >> >> This can be used to get architecture specific values easily: >> >> ((flags >> RTEMS_MM_REGION_BIT_READ) & 0x1U) << ARCH_READ_SHIFT >> > That make sense. >> >> -- >> 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 > > > > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
