On 2013-08-26 20:24, Hesham Moustafa wrote:
>> #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?I think of that solution too. But the developer may expect to apply this attribute and wonder why it does not work as expected.
Without support for cache, memory order and coherency attributes this API is useless on systems which need such stuff.
-- 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
