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

[Chris Johns]

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.

>>
>> 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