Memory Protection (Attributes)

[Chris Johns]

On 11/12/11 10:44 AM, Gedare Bloom wrote:
> I still do not have great ideas for naming. Also, I should probably
> implement these structures at the SCORE level and, if desired, export
> the structures at the user API level. Still the cumbersome naming will
> be an issue, the straightforward translation is:
> _Memory_protection_Region (drop "descriptor")
> _Memory_protection_Attributes (was permissions)
> _Memory_protection_Entry
> _Memory_protection_Domain
>
> These seem like reasonable names to me. Some viable alternatives:
> _Mprotect_Xxx -- aligns with posix-y memory protection
> _Mprotection_Xxx
> _Protection_Xxx
>
>>>
>> Yes it would be good to come up with a name that (1) has no conflicts
>> and (2) concisely captures the notion of a memory region.
>> rtems_memory_range might be a good compromise?
>>
> At the SCORE level the Region name is available. If I move most of the
> implementation to within the SCORE and consider how to adopt existing
> APIs to allow optional memory protection then the name conflict might
> go away.
>

I have also need thinking about this. Protected memory is a function of 
the API, it is not the API. We do not have _Memory_cachable_ functions.

I played with a few names then wondered if _Memory_* is the best name.

Also do we need a call that returns map of valid memory areas the BSP 
supports ?

Chris