[GSOC]Progress Report of MMU support project

Peter Dufault dufault at hda.com
Tue Jul 12 13:15:39 UTC 2011

On Jul 12, 2011, at 8:18 , Quanming Shi wrote:

> 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. 

I agree, mark the interface as "PRELIMINARY subject to discussion on mailing list".  Since you want to get this incorporated into RTEMS you want it to match the existing RTEMS practice as much as possible, but there's no need to slow down development deciding on final names today.
> 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.

I will take a look at it.

> 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?

User's can already hook  into the task switch using the "User Extensions Manager", so you should concentrate on providing the interface for the memory management and then continue to do your review of possible POSIX interfaces.  For example, if you added a "posix_typed_mem_open()" then someone could create  private per-task blocks using that,  the User Extensions Manager, and other existing RTEMS facilities.

Peter Dufault
HD Associates, Inc.      Software and System Engineering

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

More information about the users mailing list