Memory Protection (Attributes)

[Gedare Bloom]

On Tue, Dec 6, 2011 at 8:00 AM, Peter Dufault <dufault at hda.com> wrote:
>
> On Dec 5, 2011, at 5:02 , Gedare Bloom wrote:
>
>>>> I will give you my feedback without a particular order.
>>
>
> And here's some of mine.
> 1. If "rtems_memory_protection_region_descriptor" is "A region of contiguous memory" then maybe it should just be "rtems_contiguous_memory_region".
> 2. I'd suggest "mprotect" for the abbreviation for when you really want "memory_protection", though I know RTEMS likes to not abbreviate.
I'll deal with naming in the other email; thanks for your input.

> 3. I agree, "bounds" should just be "size" or "length".  I'd go with "length", "man mmap" yields "size_t length" on linux and "size_t len" in open group.
length would work well enough.

> 4. Is it possible to just use PROT_NONE, PROT_READ, PROT_WRITE, PROT_EXEC from sys/mman?  They may at least be the same definition.  Since these "PROT_FOO" are already defined I see little reason for RTEMS_MEMORY_PROTECTION_EXECUTE_PERMISSION verbosity, at most I'd go with RTEMS_PROT_EXEC.
I think we could use those symbols (with a little extra namespace
prepended). I will look into it--I'm definitely interested in
improving the permissions aspect.

> 5. I think we should add an enumeration of use cases (I'll embrace the term), it will help those who tend not to think of memory protection and real-time as going together.  My current uses:
>
> - Map code read-only
> - Unmap low page
> - Map RAM in place of flash when debugging
>
> My desired uses:
> - Per-task private heap regions.
> - Per-task private stacks.
>
Thank you for providing what interests you. I know in general per-task
private stacks is a key motivator.

> Peter
> -----------------
> Peter Dufault
> HD Associates, Inc.      Software and System Engineering
>