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

[Philipp Eppelt]

Hi,

I just want to keep this in the loop.
Where do we want to draw the line between RTEMS and host systems?

Cheers,
Philipp

On 01/16/2014 02:53 PM, Philipp Eppelt wrote:
> 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
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel
>