RFC - Time & space partitioning with RTEMS

Mon Apr 28 16:41:48 UTC 2008

One of the item I put in rtems wishing list has something in common to this
is proposal. However, I just want to put MMU and page system to RTEMS memory
management. This proposal is more focus on divide user mode and supervisor
mode.

I think this will be a tough job for only one or two people. Also, if we
want to implement this mode, lots of driver/BSP might need to change when
user what to put data from App to HW. And, how to support both non-MMU and
MMU processor is another problem.

2008/4/28 Metge Jean-Jacques <jean-jacques.metge at cnes.fr>:

> Dear all,
>
> I would like to re-open a july 2007 discussion about time and space
> partitionnig with RTEMS (see below).
> Based on my past experience of ARINC653 development in aeronautics
> domain, I really think, as Joel wrote in july 2007, that space community
> (at least), which is an important user community of RTEMS products,
> could get a big added-value from splitting RTEMS in 2 separate layers :
> - 1 low level and very light layer (let's call it "RTEMS level 1"),
> usually called "hypervisor", running in supervisor mode, aiming at
> creating robust partitions in the sense of ARINC653 standard (ie
> dedicated memory zones, dedicated I/O zones and appropriate time slices,
> with appropriate protections and monitoring). This supervisor should
> rely on a hardware MMU, meaning that appropriate hardware function
> should be specifically developed for the LEON processor
> - 1 medium level layer (let's call it "RTEMS level 2"), sometimes called
> "partition OS", running in user mode, to be hosted, if requested by one
> or several users, in one or several of the created partitions.(*)
>
> (*) The upper layer being the software applications themselves.
> Note that a the decision to use or not RTEMS layer 2 as partition OS is
> totally let to any user, which may prefer to develop its own basic
> software or to adapt its own usual  OS on top of RTEMS level 1.
>
> In order to concretly progress on this ambitious topic (I think), my
> current idea would be to :
> - first, develop a new "2-layers RTEMS" prototype (to be ran on ground,
> on an existing LEON board prototype), to be derived from an existing
> RTEMS version for LEON, in order to validate the concept
> - in a second step, develop, on the basis on this prototype, a new RTEMS
> open source version, compatible with LEON processor, and compatible with
> software development standards applicable to space on board software.
>
> Does anybody feels some interest with this exercise ?
> Does anybody already works on this idea and could be ready to provide
> some helps and/or to exchange some technical views ?
>
> Thank you by adavance for your attention.
>
> Regards
>
> Jean-Jacques
>
> ========================================================================
> ========
>
>
>
> RFC - Memory Partitioning
>
> *       Date: Tue, 24 Jul 2007 10:19:08 -0500
> *       From: joel.sherrill at oarcorp.com (Joel Sherrill)
> *       Subject: RFC - Memory Partitioning
>
> Robert S. Grimes wrote:
> > I've been thinking about this for a while too.  I haven't anything too
> > concrete to suggest at this time, but I don't want to see your post
> die
> > on the vine.  I do have some observations about the nature of the
> > proposed beast...
> >
> > One thought is that this move could result in the POSIX API becoming
> > more in line with other implementations, if each "partition" could act
> > as a "process" in the proposed RTEMS.  This would allow developers the
> > usual choices of multi-process, multi-threaded (I like to think of
> RTEMS
> > "tasks", in traditional API-speak, as "threads"), or combinations.
> >
> >
> I think you proposed using a hypervisor to put each
> RTEMS "process" inside its own container.  Then you could
> get ARINC separation.  Without reading the standard, could
> we implement an ARINC 653 manager that each RTEMS
> application runs inside of?
> > Another thought is that truly hard-real-time activities could run in a
> > suitably "high priority" partition, using such things as the rate
> > monotonic scheduler, and softer code then could run in other
> partitions.
> >
> > I certainly would not want to eliminate the current model of RTEMS,
> > especially wrt low overhead, high performance on "smaller" systems,
> > especially those without MMU.  A rather simple-minded idea could be to
> > think of such systems as "single partition" systems, which might lead
> to
> > a useful guiding principle: In the proposed new RTEMS, a single
> > partition looks, acts, feels, sounds, smells, etc. like a traditional
> > RTEMS system.
> >
> I think this is the way to go.  Writing trap interfaces
> for god knows how many services, dealing with the
> known memory issues (e.g. copying buffers, mapping
> memory, etc.), and who knows what else will be a significant
> undertaking.
>
> Approaching the problem by writing an ARINC 653 hypervisor
> will be more definable and give more value in the end to
> the RTEMS Experience. :)
>
> I think this approach would have extremely high value for
> the community and I would like to see it as a project.
> If there is interest, users from the space and aviation
> communities should be able to help sponsor this.
>
> > Just my $0.02, adjusted for inflation...
> >
> My opinion's value is about the same. :)
> > -Bob
> >
> > Charles Steaderman wrote:
> >
> >> RFC
> >>
> >> Memory Partitioning Support in RTEMS
> >>
> >> Goals:
> >> Provide task level code and memory partitioning for RTEMS. The short
> >> term goal would be for a project that contains functionality to be
> FAA
> >> certified at different certification levels (background data
> >> collection and storage certified to FAA Level C, and user interface
> >> non-certified).
> >>
> >> Proposed Strategy:
> >> Based upon some research into commercial partitioned embedded OSes
> >> (Integrity, Nucleus Secure, etc), I would like to suggest the
> >> following strategy for enhancing RTEMS. First, to provide separation
> >> from the kernel, I would propose that all RTEMS kernel calls be
> >> accessed via a TRAP or SWI. In this way, the kernel code can be
> mapped
> >> into a non-accessable memory area in order to provide protection from
> >> userland tasks. Second, I would propose that task creation and
> context
> >> switching become memory region aware. Task creation would need to be
> >> supplied memory regions and access permissions and those permissions
> >> would need to be updated on a context switch (MMU registers). In
> >> addition, each task could have its own private memory heap for
> dynamic
> >> memory allocation. This would mean that memory allocation would need
> >> to be told whether the allocation should come from the local or
> global
> >> heap.
> >>
> >> I am sure that there is a large number of issues that I have
> >> overlooked, but I would like to get people thinking about
> partitioning
> >> in RTEMS. In much the same way that desktop operating systems have
> >> benefitted from process protectsion (Win9x vs. WinNT or OS 9 vs. OS
> >> X), I think that given the present and future state of embedded
> >> hardware, embedded systems could benefit from the same robustness.
> One
> >> advantage that I believe the proposed solution has is that the code
> >> resides in a single address space, rather than virtual memory spaces.
> >> Perhaps this will cause problems with library calls and shared code,
> >> but perhaps there is a novel solution that we could employ.
> >>
> >> Thank you for your time and consideration.
> >>
> >> - Charlie
> >>
> >> _______________________________________________
> >> rtems-users mailing list
> >> rtems-users at rtems.com
> >> http://rtems.rtems.org/mailman/listinfo/rtems-users
> >>
> >>
> > _______________________________________________
> > rtems-users mailing list
> > rtems-users at rtems.com
> > http://rtems.rtems.org/mailman/listinfo/rtems-users
> >
>
>
>
> *       References:
> *       RFC - Memory Partitioning <msg00084.html>
> *       From: charlies at poliac.com (Charles Steaderman)
> *       RFC - Memory Partitioning <msg00086.html>
> *       From: rsg at alum.mit.edu (Robert S. Grimes)
> *       Prev by Date: RFC - Memory Partitioning <msg00086.html>
> *       Next by Date: GameBoy Advance BSP <msg00088.html>
> *       Previous by thread: RFC - Memory Partitioning <msg00086.html>
> *       Next by thread: RTEMS and I2C APIs <msg00111.html>
> *       Index(es):
> *       Date <date1.html>
> Thread
>
> _______________________________________________
> rtems-users mailing list
> rtems-users at rtems.com
> http://rtems.rtems.org/mailman/listinfo/rtems-users
>

-- 
Thanks & Best Regards!

Ray, Xu
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20080429/146928e7/attachment-0001.html>