<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD><TITLE>Message</TITLE>
<META http-equiv=Content-Type content="text/html; charset=iso-8859-1">
<META content=Word.Document name=ProgId>
<META content="MSHTML 6.00.2800.1597" name=GENERATOR>
<META content="Microsoft Word 11" name=Originator><LINK
href="file:///C:%5CDOCUME%7E1%5Cxur%5CLOCALS%7E1%5CTemp%5Cmsohtml1%5C01%5Cclip_filelist.xml"
rel=File-List>
<STYLE>
<!--
/* Font Definitions */
@font-face
{font-family:;
panose-1:2 1 6 0 3 1 1 1 1 1;
mso-font-alt:SimSun;
mso-font-charset:134;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:3 135135232 16 0 262145 0;}
@font-face
{font-family:"\@";
panose-1:2 1 6 0 3 1 1 1 1 1;
mso-font-charset:134;
mso-generic-font-family:auto;
mso-font-pitch:variable;
mso-font-signature:3 135135232 16 0 262145 0;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
{mso-style-parent:"";
margin:0cm;
margin-bottom:.0001pt;
text-align:justify;
text-justify:inter-ideograph;
mso-pagination:none;
font-size:10.5pt;
mso-bidi-font-size:12.0pt;
font-family:"Times New Roman";
mso-fareast-font-family:;
mso-font-kerning:1.0pt;}
/* Page Definitions */
@page
{mso-page-border-surround-header:no;
mso-page-border-surround-footer:no;}
@page Section1
{size:612.0pt 792.0pt;
margin:72.0pt 90.0pt 72.0pt 90.0pt;
mso-header-margin:36.0pt;
mso-footer-margin:36.0pt;
mso-paper-source:0;}
div.Section1
{page:Section1;}
-->
</STYLE>
</HEAD>
<BODY>
<DIV><SPAN class=416390517-28042008></SPAN><SPAN class=416390517-28042008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=416390517-28042008><FONT face=Arial color=#0000ff
size=2>Is this herebelow the RTEMS open project you are currently
evoking ?</FONT></SPAN></DIV>
<DIV><SPAN class=416390517-28042008><FONT face=Arial color=#0000ff size=2>If it
is the case, I think it is really interesting, if it is possible to implement
the hypervisor though a very light {subset+adaptation} of the current
RTEMS supercore, in order to maintain acceptable real time
performances. </FONT></SPAN></DIV>
<DIV><SPAN class=416390517-28042008><FONT face=Arial color=#0000ff size=2>What
is your opinion ?</FONT></SPAN></DIV>
<DIV><SPAN class=416390517-28042008></SPAN><SPAN class=416390517-28042008><FONT
face=Arial color=#0000ff size=2></FONT></SPAN> </DIV>
<DIV><SPAN class=416390517-28042008>
<H3><SPAN class=mw-headline>RTEMS Virtual Machine Monitor</SPAN></H3>
<P>Status: No active volunteers. </P>
<P>RTEMS based RT-VMM (Real-Time Virtual Machine Monitor). Current RTEMS can not
support to run another OS (such as Linux or uClinux). We want to add hypervisor
(or Virtual Machine Monitor) function on RTEMS, then RTEMS has the power like
XEN that can run Linux or other OS, but RTEMS also maintain original hard
Real-Time funtions. First, we will try to make RTEMS run uClinux on ARM
simulator SkyEye( <A class="external free" title=http://www.skyeye.org
href="http://www.skyeye.org/" rel=nofollow>http://www.skyeye.org</A> ), then we
will try to make RTEMS run ARM Linux on XSCALE CPU based board or SkyEye
simulator. We consider virtualization techs on Embedded RTOS area has potential
value. (from chyyuu@gmail.com)</P></SPAN></DIV>
<BLOCKQUOTE style="MARGIN-RIGHT: 0px">
<DIV></DIV>
<DIV class=OutlookMessageHeader lang=fr dir=ltr align=left><FONT face=Tahoma
size=2>-----Message d'origine-----<BR><B>De :</B> xu ray
[mailto:rayx.cn@gmail.com] <BR><B>Envoyé :</B> lundi 28 avril 2008
18:42<BR><B>À :</B> Metge Jean-Jacques<BR><B>Cc :</B>
rtems-users@rtems.com<BR><B>Objet :</B> Re: RFC - Time & space
partitioning with RTEMS<BR><BR></FONT></DIV>
<P class=MsoNormal><SPAN lang=EN-US>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.</SPAN></P>
<P class=MsoNormal><SPAN lang=EN-US>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.</SPAN></P><BR><BR>
<DIV class=gmail_quote>2008/4/28 Metge Jean-Jacques <<A
href="mailto:jean-jacques.metge@cnes.fr">jean-jacques.metge@cnes.fr</A>>:<BR>
<BLOCKQUOTE class=gmail_quote
style="PADDING-LEFT: 1ex; MARGIN: 0pt 0pt 0pt 0.8ex; BORDER-LEFT: rgb(204,204,204) 1px solid">Dear
all,<BR><BR>I would like to re-open a july 2007 discussion about time and
space<BR>partitionnig with RTEMS (see below).<BR>Based on my past experience
of ARINC653 development in aeronautics<BR>domain, I really think, as Joel
wrote in july 2007, that space community<BR>(at least), which is an
important user community of RTEMS products,<BR>could get a big added-value
from splitting RTEMS in 2 separate layers :<BR>- 1 low level and very light
layer (let's call it "RTEMS level 1"),<BR>usually called "hypervisor",
running in supervisor mode, aiming at<BR>creating robust partitions in the
sense of ARINC653 standard (ie<BR>dedicated memory zones, dedicated I/O
zones and appropriate time slices,<BR>with appropriate protections and
monitoring). This supervisor should<BR>rely on a hardware MMU, meaning that
appropriate hardware function<BR>should be specifically developed for the
LEON processor<BR>- 1 medium level layer (let's call it "RTEMS level 2"),
sometimes called<BR>"partition OS", running in user mode, to be hosted, if
requested by one<BR>or several users, in one or several of the created
partitions.(*)<BR><BR>(*) The upper layer being the software applications
themselves.<BR>Note that a the decision to use or not RTEMS layer 2 as
partition OS is<BR>totally let to any user, which may prefer to develop its
own basic<BR>software or to adapt its own usual OS on top of RTEMS
level 1.<BR><BR>In order to concretly progress on this ambitious topic (I
think), my<BR>current idea would be to :<BR>- first, develop a new "2-layers
RTEMS" prototype (to be ran on ground,<BR>on an existing LEON board
prototype), to be derived from an existing<BR>RTEMS version for LEON, in
order to validate the concept<BR>- in a second step, develop, on the basis
on this prototype, a new RTEMS<BR>open source version, compatible with LEON
processor, and compatible with<BR>software development standards applicable
to space on board software.<BR><BR>Does anybody feels some interest with
this exercise ?<BR>Does anybody already works on this idea and could be
ready to provide<BR>some helps and/or to exchange some technical views
?<BR><BR>Thank you by adavance for your
attention.<BR><BR>Regards<BR><BR>Jean-Jacques<BR><BR>========================================================================<BR>========<BR><BR><BR><BR>RFC
- Memory Partitioning<BR><BR>* Date: Tue, 24 Jul 2007
10:19:08 -0500<BR>* From: joel.sherrill at <A
href="http://oarcorp.com" target=_blank>oarcorp.com</A> (Joel Sherrill)<BR>*
Subject: RFC - Memory Partitioning<BR><BR>Robert S.
Grimes wrote:<BR>> I've been thinking about this for a while too. I
haven't anything too<BR>> concrete to suggest at this time, but I don't
want to see your post<BR>die<BR>> on the vine. I do have some
observations about the nature of the<BR>> proposed
beast...<BR>><BR>> One thought is that this move could result in the
POSIX API becoming<BR>> more in line with other implementations, if each
"partition" could act<BR>> as a "process" in the proposed RTEMS.
This would allow developers the<BR>> usual choices of
multi-process, multi-threaded (I like to think of<BR>RTEMS<BR>> "tasks",
in traditional API-speak, as "threads"), or
combinations.<BR>><BR>><BR>I think you proposed using a hypervisor to
put each<BR>RTEMS "process" inside its own container. Then you
could<BR>get ARINC separation. Without reading the standard,
could<BR>we implement an ARINC 653 manager that each RTEMS<BR>application
runs inside of?<BR>> Another thought is that truly hard-real-time
activities could run in a<BR>> suitably "high priority" partition, using
such things as the rate<BR>> monotonic scheduler, and softer code then
could run in other<BR>partitions.<BR>><BR>> I certainly would not want
to eliminate the current model of RTEMS,<BR>> especially wrt low
overhead, high performance on "smaller" systems,<BR>> especially those
without MMU. A rather simple-minded idea could be to<BR>> think of
such systems as "single partition" systems, which might lead<BR>to<BR>> a
useful guiding principle: In the proposed new RTEMS, a single<BR>>
partition looks, acts, feels, sounds, smells, etc. like a
traditional<BR>> RTEMS system.<BR>><BR>I think this is the way to go.
Writing trap interfaces<BR>for god knows how many services, dealing
with the<BR>known memory issues (e.g. copying buffers, mapping<BR>memory,
etc.), and who knows what else will be a
significant<BR>undertaking.<BR><BR>Approaching the problem by writing an
ARINC 653 hypervisor<BR>will be more definable and give more value in the
end to<BR>the RTEMS Experience. :)<BR><BR>I think this approach would have
extremely high value for<BR>the community and I would like to see it as a
project.<BR>If there is interest, users from the space and
aviation<BR>communities should be able to help sponsor this.<BR><BR>>
Just my $0.02, adjusted for inflation...<BR>><BR>My opinion's value is
about the same. :)<BR>> -Bob<BR>><BR>> Charles Steaderman
wrote:<BR>><BR>>> RFC<BR>>><BR>>> Memory Partitioning
Support in RTEMS<BR>>><BR>>> Goals:<BR>>> Provide task
level code and memory partitioning for RTEMS. The short<BR>>> term
goal would be for a project that contains functionality to
be<BR>FAA<BR>>> certified at different certification levels
(background data<BR>>> collection and storage certified to FAA Level
C, and user interface<BR>>> non-certified).<BR>>><BR>>>
Proposed Strategy:<BR>>> Based upon some research into commercial
partitioned embedded OSes<BR>>> (Integrity, Nucleus Secure, etc), I
would like to suggest the<BR>>> following strategy for enhancing
RTEMS. First, to provide separation<BR>>> from the kernel, I would
propose that all RTEMS kernel calls be<BR>>> accessed via a TRAP or
SWI. In this way, the kernel code can be<BR>mapped<BR>>> into a
non-accessable memory area in order to provide protection from<BR>>>
userland tasks. Second, I would propose that task creation
and<BR>context<BR>>> switching become memory region aware. Task
creation would need to be<BR>>> supplied memory regions and access
permissions and those permissions<BR>>> would need to be updated on a
context switch (MMU registers). In<BR>>> addition, each task could
have its own private memory heap for<BR>dynamic<BR>>> memory
allocation. This would mean that memory allocation would need<BR>>> to
be told whether the allocation should come from the local
or<BR>global<BR>>> heap.<BR>>><BR>>> I am sure that there
is a large number of issues that I have<BR>>> overlooked, but I would
like to get people thinking about<BR>partitioning<BR>>> in RTEMS. In
much the same way that desktop operating systems have<BR>>> benefitted
from process protectsion (Win9x vs. WinNT or OS 9 vs. OS<BR>>> X), I
think that given the present and future state of embedded<BR>>>
hardware, embedded systems could benefit from the same
robustness.<BR>One<BR>>> advantage that I believe the proposed
solution has is that the code<BR>>> resides in a single address space,
rather than virtual memory spaces.<BR>>> Perhaps this will cause
problems with library calls and shared code,<BR>>> but perhaps there
is a novel solution that we could employ.<BR>>><BR>>> Thank you
for your time and consideration.<BR>>><BR>>> -
Charlie<BR>>><BR>>>
_______________________________________________<BR>>> rtems-users
mailing list<BR>>> rtems-users at <A href="http://rtems.com"
target=_blank>rtems.com</A><BR>>> <A
href="http://rtems.rtems.org/mailman/listinfo/rtems-users"
target=_blank>http://rtems.rtems.org/mailman/listinfo/rtems-users</A><BR>>><BR>>><BR>>
_______________________________________________<BR>> rtems-users mailing
list<BR>> rtems-users at <A href="http://rtems.com"
target=_blank>rtems.com</A><BR>> <A
href="http://rtems.rtems.org/mailman/listinfo/rtems-users"
target=_blank>http://rtems.rtems.org/mailman/listinfo/rtems-users</A><BR>><BR><BR><BR><BR>*
References:<BR>* RFC - Memory
Partitioning <msg00084.html><BR>* From: charlies
at <A href="http://poliac.com" target=_blank>poliac.com</A> (Charles
Steaderman)<BR>* RFC - Memory Partitioning
<msg00086.html><BR>* From: rsg at <A
href="http://alum.mit.edu" target=_blank>alum.mit.edu</A> (Robert S.
Grimes)<BR>* Prev by Date: RFC - Memory Partitioning
<msg00086.html><BR>* Next by Date: GameBoy
Advance BSP <msg00088.html><BR>* Previous by
thread: RFC - Memory Partitioning <msg00086.html><BR>*
Next by thread: RTEMS and I2C APIs <msg00111.html><BR>*
Index(es):<BR>* Date
<date1.html><BR>Thread<BR><BR>_______________________________________________<BR>rtems-users
mailing list<BR><A
href="mailto:rtems-users@rtems.com">rtems-users@rtems.com</A><BR><A
href="http://rtems.rtems.org/mailman/listinfo/rtems-users"
target=_blank>http://rtems.rtems.org/mailman/listinfo/rtems-users</A><BR></BLOCKQUOTE></DIV><BR><BR
clear=all><BR>-- <BR>Thanks & Best Regards!<BR><BR>Ray, Xu
</BLOCKQUOTE></BODY></HTML>