> 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. 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. Hence, at compile time the guest system is missing the implementation of this host specific functions. 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
