<GSoC MMU project> Avoid translating attributes and move it from High-level to BSP code.

[Gedare Bloom]

What about having a struct that is declared (typedef) in the
high-level layer and has its definition in the BSP? the BSP will know
how to handle the struct; the high-level code would have to pass
around the attributes as a pointer to the struct since there will be
incomplete type information for it.

On Sat, Jul 14, 2012 at 5:24 PM, Hesham Moustafa
<heshamelmatary at gmail.com> wrote:
> Hi,
>
> Currently MMU attributes are defined at High-level code, So when
> setting/changing it, that involves translating attributes to the BSP code
> (low-level layer) to form a bit pattern that is compatible with cpu (
> powerpc) attributes pattern for page table entry. The problem is we want to
> avoid that translation and changing these attributes directly through BSP
> layer only. I was thinking of some solutions and i will list it hoping to
> get some feed backs.
>
> 1- The first solution is to create a type ( uint32_t ) for permissions, add
> to this some functions like rtems_xxx_set_write, rtems_xxx_set_read_only
> ........... etc. These functions invokes BSP functions and it set bits
> exactly mapping to the cpu page table bits. After that it can be ORed with
> cpu page table attributes ( i.e setting some protection permissions ).
>
> 2- To create a dummy struct at high-level code that contains boolean fields
> for each attribute may exist and provided by most HWs. So when
> setting/unsetting attributes read this struct, collect "true" values, form a
> bit pattern maps to cpu page table attributes bits and setting it. I think
> this will solution will take longer time for checking true fields and
> forming a bit pattern.
>
> 3- Create function that takes attribute type ( i.e READ_ONLY ) and boolean
> parameter ( to determine whether to set/unset it ) and then change cpu page
> table attributes bits according to parameters.
>
> I would appreciate any other useful solutions.
>
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>