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

[Philipp Eppelt]

On 01/14/2014 08:36 PM, Chris Johns wrote:
> 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.
We should put this into the troubleshooting section of the README file.
If you are running RTEMS on POK, I assume you know what you are getting
yourself into and therefore read the README?

> 
>>>
>>>>
>>>> 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 ?
Yes.

> 
>> 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 ?
I introduced some new system calls to POK, as POK was not able to attach
partitions to interrupt sources. I would say it is not likely to change
often, but it does change from time to time.
Currently, libpart.a includes everything a POK partition is configured
for, so RTEMS compiles a valid POK partition.
Looking at my source code[0] I agree, that it is only using the syscall
interface (printf l.117 can directly be replaced by a syscall). But if
we want to use communication functionality with other partitions in the
system (e.g. network card driver), we have to pull a lot of stuff into
RTEMS[1].

In the design I made the distinction between host world and RTEMS world.
And in the RTEMS world I don't want to care about how exactly the
message gets to the network driver, I just want to invoke one function.
The rest is dependent on the host system and therefore nothing I should
be bothered with.
By now, we know we will end up with one BSP per host per architecture,
but I still think, the host implementation should stay on the host side.
Hence, libpart.a is implemented in POK.

As we end up with one BSP per host, one could argue, to expand the host
specific part of the virtualization layer into the BSP. But then we have
to track the changes in a foreign project and not just update the host
implementation, when we change something.
But the stronger argument from my point of view is the transparent
implementation of the layer.


Cheers,
Philipp


[0] https://github.com/phipse/pok/blob/master/examples/rtems-guest/hello.c
[1] https://github.com/phipse/pok/tree/master/libpok