<div dir="ltr">That was the first experience. Write your proposal and keep discussing your ideas about the project with the community :)<div><br></div><div style>Ok! I have to explore that architecture better. </div></div>
<div class="gmail_extra"><br><br><div class="gmail_quote">On Mon, Apr 8, 2013 at 3:04 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 Cláudio,<br>
<br>
okay. So do you have experiences, which I need to consider up front, when writing my proposal? Otherwise I just write one and await your comments :)<div class="im"><br>
<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Can you further explain your L4 based approach? Does it seem like a<br>
modified jump table?<br>
</blockquote>
<br></div>
Yes, indeed. The L4_EXTERNAL_FUNC macro defines three sections: .data.l4external.str, *.symtab and *.jmptbl and in the .text section an resolver part, that jumps to __l4_external_resolver. This pointer needs to be passed at system startup to the guest system.<br>
<br>
When compiling the L4 wrapper code, the .data.l4external.str is scanned and every functionname gets copied in a new header file (func_list.h).<br>
These function have the form EF(func) and EF() gets defined in the resolver file. First to produce the function definitions, second after a redefine of EF to produce a 'else-if' list, which generates a kind of lookup table.<br>
So when the function is called the first time, the programm jumps to the resolver function, which looks for the function name in the lookup table, replaces itself with the correct address for future references and returns with a call to the searched function.<br>
<br>
Regards,<br>
Philipp<div class="im"><br>
<br>
<br>
On 04/07/2013 03:07 PM, Cláudio Silva wrote:<br>
</div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">
Hello Philipp,<br>
<br>
RTEMS on POK was meant as a first virtualization experience for RTEMS<br>
on top of an open source ARINC 653 compliant hypervisor. A future<br>
generic paravirtualization interface would be build based on this first<br>
experience.<br>
System calls are there to maintain the independence between RTEMS and<br>
the partitioning kernel. Of course the system calls (or hypercalls) can<br>
(should) be hidden by a small library that is linked against the<br>
virtualized operating system. Originally, POK uses system calls to<br>
interface between the ARINC 653 executive in each partition and the<br>
partitioning kernel.<br>
<br>
Can you further explain your L4 based approach? Does it seem like a<br>
modified jump table?<br>
<br>
<br>
Regards,<br>
Cláudio Silva<br>
<br>
<br>
On Sat, Apr 6, 2013 at 11:23 PM, Philipp Eppelt<br>
<<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@mailbox.tu-<u></u>dresden.de</a><br></div><div><div class="h5">
<mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@<u></u>mailbox.tu-dresden.de</a>>> wrote:<br>
<br>
Hi,<br>
<br>
thanks for the source, Gedare. I built the tool chain and the<br>
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<br>
partition application (e.g. console writes). From my understanding,<br>
one aspect of the project is to provide a defined interface to run<br>
RTEMS on various other hypervisors. Why did you choose syscalls to<br>
provide this interface?<br>
<br>
From my experience there are two other ways to achieve this<br>
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<br>
have to be implemented in the host and made available in form of a<br>
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<br>
L4_EXTERNAL_FUNC(..) macro. This macro adds the function to special<br>
sections in the binary, which are defined in the linkcmds file.<br>
Therefore no undefined references occur.<br>
While compiling the wrapper code in L4 the mentioned sections in the<br>
RTEMS binary are scanned and the function addresses get fixed.<br>
This is a very abbreviated explanation. So for further reading I<br>
recommend these files on github [0].<br>
<br>
Both ways look like a better portable approach to me, but I assume<br>
they are not as efficient as yours. Mainly, because there will be at<br>
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<br>
your decision?<br>
<br>
<br>
Regards,<br>
Philipp<br>
<br>
<br>
<br>
[0]<br>
* L4_EXTERNAL_FUNC'tions.<br></div></div>
<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><div class="im">
<br>
<<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:<br></div>
<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><div class="im">
<br>
<<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:<br></div>
<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><div class="im">
<br>
<<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><u></u>><br>
* Grab function names; Line 20:<br></div>
<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="im">
<br>
<<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>><br>
<br>
<br>
<br>
On 04/03/2013 10:32 PM, Gedare Bloom wrote:<br>
<br></div>
The code is here: <a href="https://github.com/jolkaczad/__rtems" target="_blank">https://github.com/jolkaczad/_<u></u>_rtems</a><div class="im"><br>
<<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<br>
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></div>
<<a href="mailto:philipp.eppelt@mailbox.tu-__dresden.de" target="_blank">philipp.eppelt@mailbox.tu-__<u></u>dresden.de</a><div class="im"><br>
<mailto:<a href="mailto:philipp.eppelt@mailbox.tu-dresden.de" target="_blank">philipp.eppelt@<u></u>mailbox.tu-dresden.de</a>>> wrote:<br>
<br>
Hi,<br>
<br>
I am interested in the paravirtualization project[0] for<br>
this years round of<br>
the Google Summer of Code. Unfortunately, I am unable to<br>
find results of the<br>
mentioned gsoc2011 project. I guess it's the hypervisor<br>
project, but I am<br>
not allowed to view the proposal, neither have I found any<br>
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]<br></div>
<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>
<<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> <mailto:<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>
<<a href="http://www.rtems.org/mailman/listinfo/rtems-users" target="_blank">http://www.rtems.org/mailman/<u></u>listinfo/rtems-users</a>><br>
<br>
<br>
</blockquote>
</blockquote></div><br></div>