[GSOC]Progress Report of MMU support project

[Quanming Shi]

Glad to see your discussion and thank you for all of your feedback

2011/7/12 Peter Dufault <dufault at hda.com>

> > What is the difference between memp and mprot?  RTEMS in general uses no
> > abbreviations in its API.
> Quanming and I should have had more discussions on the mailing list to get
> these issues brought up earlier, I take the blame for not pushing that.


I think the function name is not a big issue. Anyway , we can change all
function names with several commands.


2011/7/12 Peter Dufault <dufault at hda.com>

> I think that if Quanming can get it to the point that
>
> 1. There's a clean abstraction for differing hardware  (Quanming, the
> discussions we've had about that should also go onto your Wiki);
>
Yes,I should take care of the abstraction and I am working on it.
I think there should be some convention in rtems  about this. I noticed the
rtems source files "cache.h" and "Cache_manager.c"  in "/libcpu/share/src".
This looks like a  good example in rtems.
It is not as same as the way you show me but I think it might suit rtems
more.I think I can add the "attribute check" and "tlb operation" to the same
place in this way.

2. (I haven't discussed this with Quanming yet) The interface described in
> posix_typed_mem_open() either is present or is trivially implementable

then the interface will be useful for simple uses such as creating a private
> per-task memory block, etc. and would be a good candidate to go into the
> source tree.
>
I think the task support  would need  to change the data structure and the
add some code to the task switch part.  should this have priority over
posix?

2011/7/12 Sebastian Huber <sebastian.huber at embedded-brains.de>

> > rtems_status_code
> > rtems_memp_alut_set_attr(rtems_mprot_alut *p_ret,
> > rtems_memp_access_attr* new_attribute);
> > rtems_status_code
> > rtems_memp_get_attr(rtems_mprot_alut *p_ret, rtems_memp_access_attr*
>  attr);
> [...]
>
> One problem with set and get methods is that you cannot atomically set and
> get
> things.  Thus rtems_task_set_priority() can be used for example to set and
> get
> the priority of a task (there are similar functions in the RTEMS API).
>
what do you mean atomically set and get things? I don't understand it
I agree the set methods should accept a new attr and a pointer param to the
old attr.


2011/7/12 Aanjhan R <aanjhan at gmail.com>

> Having worked on this project 2 yrs back, I am happy to see it
> progress through to this stage [which Joel and Thomas would agree on
> the ambitious quotient level of the proposal]. However, as I mentioned
> in the proposal review, it would be very helpful to the community if
> you can start thinking on slowly [in small parts] try to integrate
> "relevant" code into the trunk. Its not trivial and a solid "start" to
> this project would be when the first few bits go into the source
> control.
>
> Note: Might require some hardcore convincing as to why this would be useful
> ;-)
>
 Glad to see your reply.  I will try to get this code integrated into the
trunk .

-- 
Best regards

Quanming Shi
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20110712/9e40a113/attachment-0001.html>