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

[Philipp Eppelt]

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:
>>>>> On 7/01/2014 12:18 pm, Joel Sherrill wrote:
>>>>>>
>>>>>> On 1/6/2014 5:14 PM, Chris Johns wrote:
>>>>>
>>>>> If RTEMS is to offer a Pok based solution the project needs to address
>>>>> all these factors.
>>>>>
>>>>>> This is an important capability for the growth of RTEMS as a project.
>>>>>> We
>>>>>> need to
>>>>>> lay the groundwork so we can eventually test Pok, help it grow,  and
>>>>>> ensure
>>>>>> its stability. In a perfect world, it would have good test results
>>>>>> before we  test
>>>>>> Pok+RTEMS and put it through our acceptance tests.
>>>>>>
>>>>>
>>>>> I was not wishing to address acceptance tests. I am currently only
>>>>> concerned with patches entering RTEMS and knowing this code is being
>>>>> tested. As we move to constant integration we need to make sure the
>>>>> Pok
>>>>> component is maintained or we risk it rotting. I would rather have the
>>>>> commitment to support it addressed up front. I have no idea what this
>>>>> is.
>>>>
>>>> I don't have a script to build all this. If I update things in POK I
>>>> rebuild 'libpart.a' and copy it to RTEMS.
>>>
>>> Why not use an installed version directly from pok ? I do not think
>>> adding binary blobs to RTEMS is a good idea.
>> To build POK you need to set an environment variable $POK_PATH. So you
>> could grab libpart.a from e.g.
>> $POK_PATH/examples/rtems_guest/generated-code/cpu/part1/libpart.a. But
>> the user must be made aware to change this path for his setup.
> 
> Reliance on environment variables is not good. The path needs to be part
> of RTEMS's configuration.

Hmm, yeah you are right. To have a single place to look for options is
better.

>>>> This provides all information
>>>> for the interaction with POK to RTEMS.
>>>
>>> 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.

>>>>
>>>> More details, but missing --enable-paravirt, here:
>>>> http://phipse.github.io/rtems/blog/2013/07/08/HelloWorld/
>>>>
>>>> Do you want to test if the code compiles or if it runs on the system?
>>>
>>> I am looking a little further into the future and Joel has been clear
>>> that POK is important so we need to get the testing (compile and
>>> running) sorted and to manage its integration so it does not bitrot.
>>> This means RTEMS developers need easy access to POK, it tools and the
>>> ability to run it so we can do this. It might be POK is only built and
>>> tested on the RTEMS test hardware via buildbot when code is committed
>>> however we need to set this up and then maintain it.
>>>
>>> As stated before my concern is constant integration and what it brings.
>>> The end objective is to have buildbot build and test all commits to a
>>> certain level. This level is still be determined and relates to the
>>> resources available and time it takes. Once working and after things
>>> settle we will start to remove the parts from RTEMS that are not being
>>> tested for cannot be tested. When the core team makes an RTEMS release
>>> we need to make be clear what works and what does not and if POK is not
>>> being built and being tested over time it will rot and then we would
>>> need to consider it for removal. It makes no sense to release code in
>>> RTEMS that does not build or has not been tested.
>>>
>>>> You can shortcut the compile step, by providing a 'libpart.a' to copy
>>>> into virtualpok/. Then it's just configure and compile.
>>>
>>> As a rule I tend not to like the coping of files into the tree. Could a
>>> path to pok be passed to configure with the --enable-paravirt option ?
>>>
>> I would prefer a file in 'virtualpok' to set the path for libpart.a.
>> Because the Makefile in 'virtualpok' is the one checking for the
>> presence of 'libpart.a' and you don't need to reconfigure the if you
>> change the path.
> 
> 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?

> 
>>
>>>> The execution test needs all steps, including a version of POK
>>>> supporting this.
>>>> My development version can be found on github:
>>>> https://github.com/phipse/pok
>>>>
>>>> For more details on POK - including a what works and what doesn't - I
>>>> would write a wiki page.
>>>>
>>>>
>>>> Was this what you were looking for? Or did I miss the point?
>>>>
>>>
>>> Yes it is and I think my understanding is becoming clearer.
>>>
>>> I am wondering if the RSB should get a pok section.
>> RSB?
>>
> 
> http://www.rtems.org/ftp/pub/rtems/people/chrisj/source-builder/source-builder.html
Thanks.



Cheers,
Philipp