[PATCH] i386/virtualpok BSP, virtual BSP to be used with POK, build with enable-paravirt

[Chris Johns]

On 15/01/2014 1:58 am, Philipp Eppelt wrote:
> On 01/14/2014 12:32 PM, Chris Johns wrote:
>> On 14/01/2014 12:40 am, Philipp Eppelt wrote:
>>> On 01/12/2014 10:19 PM, Chris Johns wrote:
>>>> On 13/01/2014 2:39 am, Philipp Eppelt wrote:
>>>>> On 01/11/2014 11:50 PM, Chris Johns wrote:
>>>>>> On 12/01/2014 12:45 am, Philipp Eppelt wrote:
>>>>>>> On 01/10/2014 10:27 PM, Chris Johns wrote:
>>>>>>>> On 7/01/2014 9:14 pm, Philipp Eppelt wrote:
>>>>>>>>> On 01/07/2014 04:25 AM, Chris Johns wrote:
>>>>>>>> Does this include headers ?
>>>>>>> POK separates kernel and partition code. The kernel code is not
>>>>>>> affected
>>>>>>> by the partitions running on top. And each partition has the
>>>>>>> 'knowledge'
>>>>>>> of how to communicate with the kernel. libpart.a consits of this
>>>>>>> communication code or 'partition base code' and the implementation of
>>>>>>> the functions in virtualizationlayercpu.h and
>>>>>>> virtualizationlayerbsp.h.
>>>>>>> Or what do you mean with headers?
>>>>>>
>>>>>> Where do the virtualizationlayercpu.h and virtualizationlayerbsp.h
>>>>>> come
>>>>>> from and live ?
>>>>>>
>>>>> In libbsp/i386/virtualpok/include. The files are part of this patch.
>>>>
>>>> What is used to build the library externally ?
>>>>
>>>> I do not think having headers in RTEMS for a library built outside is a
>>>> good idea. An interface change in the library not reflected in RTEMS
>>>> headers will be difficult to find.
>>>
>>> The header files define the virtualization layer in RTEMS. They are not
>>> part of POK.
>>
>> Yet the code is built by POK. I am a little confused by this.
>>
>>> The header files define the functions a host has to
>>> implement to run this particular RTEMS BSP.
>>
>> Sure.
>>
>>> All hardware interactions a BSP/CPU does go through this layer and are
>>> handled on the host system. RTEMS defines the function necessary and POK
>>> is providing the implementation via libpart.a.
>>
>> How does POK see these definitions so it can build the library ?
> Copy & Paste.
> I kept the two systems separated and I think gcc, couldn't resolve links.
>

This is what I suspected and my concern. The library and header files 
need to be in a single location together so users do not get mismatches 
if anything changes.

>>
>>>
>>> For examples, the console driver calls _BSP_Virtual_Char_read/write,
>>> defined in virtualizationlayerbsp.h.
>>> The implementation is done in POK and passed to RTEMS at compile time
>>> via libpart.a
>>
>> What is the interface used in POK to build this RTEMS interface ?
> What do you mean?
>
> The header files are written for RTEMS

This is what I mean by the POK/RTEMS interface. I suspect my wording was 
not correct before.

>, so the compiler has something to work with.

I assume you mean the POK compiler to build the library as part of POK 
and also the RTEMS compiler as part of RTEMS to reference the library. 
Is this true ?

> The linker uses the library provided by POK to resolve the
> undefined references.
> The POK implementation includes a copy of these header files. Hence, the
> linker can match the names.

Why not move this libpart code in RTEMS. I assume it just needs to 
reference POK system call interfaces which I assume are standard and do 
not change ?

Chris