[PATCH] mm: Add infrastructure for basic memory

[Gedare Bloom]

On Wed, Feb 20, 2013 at 5:24 PM, Stephen Tether
<tether at slac.stanford.edu> wrote:
> On 02/20/2013 06:11 AM, rtems-devel-request at rtems.org wrote:
>> Today's Topics:
>>
>>    1. Re: [PATCH] mm: Add infrastructure for basic memory
>>       management (Sebastian Huber)
>>    2. Re: RFC: ARM GCC changes (Sebastian Huber)
>>    3. [PATCH] libblock: Do resource allocation in one place
>>       (Sebastian Huber)
>>    4. Re: [PATCH] mm: Add infrastructure for basic memory
>>       management (Gedare Bloom)
>
> I, too, would prefer integer encodings of the memory attributes rather
> than having a setter function for each attribute, since it would make it
> possible to change multiple attributes at once.
>
OK it makes sense.

> Will these proposed MM routines perform the cache cleaning that is
> required for some types of attribute changes? I have in mind the loading
> of code into memory that is writable and non-executable and then
> changing the memory to read-only executable.
>
Yes. The code that is specific to the MMU will need to ensure that
cache and TLB are flushed if relevant attributes or mappings change.

> Have you considered exporting memory types that reflect the memory's
> function rather than (or in addition to) the raw MMU attributes? The
> trouble with the latter approach is that it allows arbitrary
> combinations of attributes many of which may be useless or even harmful.
> Here's a set of functional attributes that seem good to me, at least for
> ARM:
>
> Function                ARM MMU settings
> ---------------         ------------------------
> CODE                    cached
> DATA                    non-executable, writable, cached
> CONSTANTS               non-executable, cached
> CALL_STACK              non-executable, writable, cached
> DMA_BUFFER              non-executable, writable
> PAGE_TABLE              non-executable, writable, cached
> DEVICE                  non-executable, ordered or device
>
This is a good idea. We will obviously need to make these somewhat
more flexible, but we can try to keep developers from shooting
themselves in the foot.

> Independently of these functional settings one could have a SHARED flag
> and a cache-policy setting, e.g., WRITE_BACK or WRITE_THROUGH. Add a
> number of customizable functional settings to cover corner cases.
>
> Even this scheme isn't completely orthogonal. On the ARM, for example,
> SHARED|WRITE_THROUGH|PAGE_TABLE would be invalid since shared page
> tables must be WRITE_BACK. Then, too, perhaps this sort of thing doesn't
> belong in the lowest level of MMU support.
>
I think the lowest/lower levels must determine whether the setting is
plausible, since on some other CPU it might be possible to have (for
example) shared write-through page tables. We might be able to do some
filtering at higher levels for common features though.

> - Steve Tether
>   SLAC DAT Group
>
Thanks for the feedback. This project is slow-moving, but hopefully I
can keep pushing on it and eventually nudge it into something usable.

-Gedare

> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel