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

[Philipp Eppelt]

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. The header files define the functions a host has to
implement to run this particular RTEMS BSP.
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.

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

> 
>>>
>>> I prefer setting via configure and no other backdoor method such as
>>> special files or environment variables. It makes configuration audits
>>> much simpler.
>>>
>>> If you need to switch versions when testing pok builds I suggest you use
>>> something external to RTEMS. For example symlinks work where you
>>> reference a symlink from RTEMS and move things as you want via the
>>> symlink.
>> On a second thought, the place of libpart in the users system shouldn't
>> change often. You first need to build the host environment for RTEMS
>> (POK) and then the location of libpart.a shouldn't change.
>>
>> ToDo:
>> * extend --enable-paravirt to --enable-paravirt=/path/to/libpart.a
>> * what else?
>>
> 
> Just the headers.
> 
> Chris