Memory Protection (Attributes)
gedare at rtems.org
Tue Dec 6 17:19:05 UTC 2011
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 Dufault
> HD Associates, Inc. Software and System Engineering
More information about the devel