<div dir="ltr">Hello Philipp,<div><br></div><div style>RTEMS on POK was meant as a first virtualization experience for RTEMS on top of an open source ARINC 653 compliant hypervisor. A future generic paravirtualization interface would be build based on this first experience.</div>
<div style>System calls are there to maintain the independence between RTEMS and the partitioning kernel. Of course the system calls (or hypercalls) can (should) be hidden by a small library that is linked against the virtualized operating system. Originally, POK uses system calls to interface between the ARINC 653 executive in each partition and the partitioning kernel. </div>
<div style><br></div><div style>Can you further explain your L4 based approach? Does it seem like a modified jump table?</div><div style><br></div><div style><br></div><div style>Regards, </div><div style>Cláudio Silva</div>
</div><div class="gmail_extra"><br><br><div class="gmail_quote">On Sat, Apr 6, 2013 at 11:23 PM, Philipp Eppelt <span dir="ltr"><<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@mailbox.tu-dresden.de</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Hi,<br>
<br>
thanks for the source, Gedare. I built the tool chain and the example code and thanks to the great Manual(!), it's working.<br>
<br>
<br>
Now, I have a question regarding the design.<br>
<br>
You have chosen to use syscalls to provides functionality to the partition application (e.g. console writes). From my understanding, one aspect of the project is to provide a defined interface to run RTEMS on various other hypervisors. Why did you choose syscalls to provide this interface?<br>
<br>
>From my experience there are two other ways to achieve this functionality.<br>
<br>
The first is pretty close, but with a different compile process.<br>
There is one header file with function definitions. These functions have to be implemented in the host and made available in form of a library, which is used while linking RTEMS.<br>
<br>
The second way is used in L4Linux and I did it the same way in L4RTEMS.<br>
Inside the guest system, host functionality is wrapped with a L4_EXTERNAL_FUNC(..) macro. This macro adds the function to special sections in the binary, which are defined in the linkcmds file. Therefore no undefined references occur.<br>
While compiling the wrapper code in L4 the mentioned sections in the RTEMS binary are scanned and the function addresses get fixed.<br>
This is a very abbreviated explanation. So for further reading I recommend these files on github [0].<br>
<br>
Both ways look like a better portable approach to me, but I assume they are not as efficient as yours. Mainly, because there will be at least on more function call to get into the kernel.<br>
<br>
I am sure, there is a lot I missed. So what other reasons led you to your decision?<br>
<br>
<br>
Regards,<br>
Philipp<br>
<br>
<br>
<br>
[0]<br>
* L4_EXTERNAL_FUNC'tions. <a href="https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/handler.c" target="_blank">https://github.com/phipse/<u></u>L4RTEMS/blob/master/c/src/lib/<u></u>libbsp/l4vcpu/pc386/startup/<u></u>handler.c</a><br>
* Section magic: <a href="https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/l4lib.h" target="_blank">https://github.com/phipse/<u></u>L4RTEMS/blob/master/c/src/lib/<u></u>libbsp/l4vcpu/pc386/startup/<u></u>l4lib.h</a><br>
* Resolver the sections: <a href="https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/res.c" target="_blank">https://github.com/phipse/<u></u>L4RTEMS/blob/master/l4/pkg/<u></u>RTEMS_wrapper/server/src/res.c</a><br>
* Grab function names; Line 20: <a href="https://github.com/phipse/L4RTEMS/blob/master/l4/pkg/RTEMS_wrapper/server/src/Makefile" target="_blank">https://github.com/phipse/<u></u>L4RTEMS/blob/master/l4/pkg/<u></u>RTEMS_wrapper/server/src/<u></u>Makefile</a><div class="HOEnZb">
<div class="h5"><br>
<br>
<br>
On 04/03/2013 10:32 PM, Gedare Bloom wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
The code is here: <a href="https://github.com/jolkaczad/rtems" target="_blank">https://github.com/jolkaczad/<u></u>rtems</a><br>
<br>
There is a lot to do, although I don't know how what is reasonable in<br>
the scope of a GSOC project. I think somehow last year's project was<br>
too ambitious and did not meet all its goals.<br>
<br>
On Wed, Apr 3, 2013 at 4:20 PM, Philipp Eppelt<br>
<<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@mailbox.tu-<u></u>dresden.de</a>> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Hi,<br>
<br>
I am interested in the paravirtualization project[0] for this years round of<br>
the Google Summer of Code. Unfortunately, I am unable to find results of the<br>
mentioned gsoc2011 project. I guess it's the hypervisor project, but I am<br>
not allowed to view the proposal, neither have I found any related source<br>
code.<br>
<br>
So is there anything left from the project to build upon?<br>
<br>
Regards,<br>
Philipp<br>
<br>
<br>
[0] <a href="http://www.rtems.org/wiki/index.php/RTEMS_Paravirtualization" target="_blank">http://www.rtems.org/wiki/<u></u>index.php/RTEMS_<u></u>Paravirtualization</a><br>
______________________________<u></u>_________________<br>
rtems-users mailing list<br>
<a href="mailto:rtems-users@rtems.org" target="_blank">rtems-users@rtems.org</a><br>
<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-users</a><br>
</blockquote></blockquote>
</div></div></blockquote></div><br></div>