Including paravirtualization headers in RTEMS

Sun May 25 18:39:50 UTC 2014

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 <claudiodcsilva at 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 <chrisj at 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.Mauderer at 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 at rtems.org
>>> http://www.rtems.org/mailman/listinfo/rtems-devel
>>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel