Sorry all, miss send. Returning to where I was: 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 by the bootloader.
Typically, you have a thin abstraction layer defining simple functions that will trap into the partitioning kernel. Something like: https://github.com/t-crest/ospat/blob/master/libpok/middleware/portqueueingsend.c In POK + RTEMS case, this library is being compiled by POK's compiler and then linked to each partitions' executable. When this partition is an RTEMS one, the remaining binaries (RTEMS+Application) were compiled with the RTEMS' compiler. Therefore you are linking two sets of binaries produced by different compilers. I guess this is also true for the recently submitted Xtratum BSP. We have several options available: - Let the two binaries (RTEMS + abstraction lib), compiled with different compilers, to be linked together (how it is currently happening) - Compile the partitioning kernel abstraction layer with the RTEMS compiler - this will result in a complex configuration and build procedure. - Implement the functionality of the abstraction layer completely inside RTEMS as part of the libbsp/libcpu - This can be a good solution for the CPU/TImer/Interrupt part of the abstraction layer. However, for other elements like the queueing and sampling port APIs that have no match inside RTEMS... - Best Regards, Cláudio On Sun, May 25, 2014 at 7:22 PM, Cláudio Silva <claudiodcsi...@gmail.com> wrote: > 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
