Hello Chris, Yes, Partitions are fully linked executables created "off-line". No linking occurs in run-time. The partition elf is simply loaded in to memory by a partition loader or the bootloader.
Typically, you have a thin abstraction layer defining simple functions that will trap into the partitioning kernel. Something like: On Sat, May 24, 2014 at 12:27 AM, Chris Johns <chr...@rtems.org> wrote: > 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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
