[PATCH] mm: Add infrastructure for basic memory
gedare at rtems.org
Thu Feb 21 17:10:46 UTC 2013
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
> 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.
> rtems-devel mailing list
> rtems-devel at rtems.org
More information about the devel