On 23/05/2014 6:46 pm, Philipp Eppelt wrote:
On 05/21/2014 03:54 PM, Gedare Bloom wrote:> On Wed, May 21, 2014 at 4:04 AM,
Christian Mauderer
<christian.maude...@embedded-brains.de> wrote:
First of all: Thanks for your comments. You will find answers below.
Am 20.05.2014 16:58, schrieb Gedare Bloom:
That is correct. It's part of XtratuM. Is there some preferred way of
marking such headers?
Not that I know of. We have discussed a similar issue with the POK
paravirtualization project. The problem is to allow external code
linking to RTEMS. The design should be considered carefully and
probably discussed in a separate thread.
To pick up this discussion, I like first to picture the problem, second
to collect possible solutions and third name some known problems with
the solutions.
Thank you for posting this email. I followed the links and looked at the
code and realised I need to ask more questions.
In a paravirtualized environment we need to make function calls from our
guest system to the host system. The implementation of these functions
rely sole on the host system.
Are they function calls ? To me a function call assumes some sort of
linking process between the guest and the host system either static or
via some form of runtime binding, ie a link editor. I also assume a
guest is an RTEMS partition executable and the host is the POK
microkernel providing the partitioned environment in some sort of
protective environment.
Hence, at compile time the guest system is missing the implementation of
this host specific functions.
My understanding is partitions are loaded into an ELF image that POK
loads and executes. Is there some sort of linking happening when the
partition is written into the ELF image or when it is being loaded ?
For me this is the really important because I am wanting to first
understand the which pieces of code are compiled into object files and
by which compilers and then archived into static libraries and then
linked to any RTEMS code compiled with an RTEMS compiler. I do not
understand if there are function calls into the POK kernel or syscall
type calls which I consider an ABI, ie a trap or VM exception.
If I can understand these needs I will be in a better position to help
with the remaining topics in this email.
Chris
To provide the guest system with the function implementation there are a
couple of possible solutions.
(A) Provide a host library
The host compiles a library containing the function implementations
including all dependencies. This host library is passed to the guest
system, to resolve the `undefined reference` errors during link time.
In the case of POK+RTEMS the resulting RTEMS binary is a valid POK
partition and can run without further modifications.
The recently propose XantruM BSP seems to follow a similar approach.
(B) Use function stubs and build a jump table in the host
The guest system makes use of function stubs, written into a special
section in the binary to build. This section is analysed by the host
system to intercept function calls and replace them with the host
implementation of the calls.
This approach is used in L4Linux and I gave it a shot in L4RTEMS.
[1] shows the macro for the function stubs, [2] the hosts resolver part.
(C) add your solution
Problems with the solutions
P(A) Dependencies and foreign code
The library is host code, which has to be maintained, which can get out
of sync between BSP and host. Licensing is another question.
To my knowledge this approach won't get merged upstream.
P(B) Support by the host system
The host system needs a piece of code, loading the guest binary and
providing it with knowledge about the environment (external_resolver).
We haven't discussed this approach in detail.
I hope, this gives a good overview and we can have a fruitful discussion.
Cheers,
Philipp
[1]
https://github.com/phipse/L4RTEMS/blob/master/c/src/lib/libbsp/l4vcpu/pc386/startup/l4lib.h
[2]
https://github.com/phipse/L4RTEMS/blob/f5a32ed0121b3e5f0ac8ae4c53e636eab2257fb1/l4/pkg/RTEMS_wrapper/server/src/res.c
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
