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

[Chris Johns]

Hi Philipp,

Sorry about the delay. It is the holiday season here.

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:
>>>> On 7/01/2014 4:24 am, Joel Sherrill wrote:
>>>>> On 1/6/2014 11:13 AM, Philipp Eppelt wrote:
>>>>>> Where are we on this?
>>>>> I think I was OK on it. If Gedare is also, then it should be merged.
>>>>>
>>>> How will this change be tested on a regular basis ? As we move to
>>>> constant integration testing we need a way to test this code.
>>> Philipp.. can you provide us a "test plan"? That is, how you build and
>>> test today
>>> for what you have. I know that it is likely only a couple of tests at
>>> this point
>>> from an RTEMS perspective.
>>>> I would like to understand how this extra dependency is tested and
>>>> managed on an on going basis before getting my support.
>>> Agreed. We need to be conscious of this.
>>>
>>> Is a test plan sufficient? We don't have the infrastructure currently to
>>> automate
>>> testing this. I really hope Philipp enjoyed the project and will stay
>>> involved and help
>>> us grow this.
>>
>> Currently I do not know what I would need to run "Pok", can I build it
>> from source and what is needed to do this ? Does Pok itself need special
>> tools ?
>>
>> What development hosts does Pok support ?
>
> POK is short for Partitioned Operating system Kernel. It supports x86,
> ppc and sparc. You can obtain the source here:
> http://pok.safety-critical.net/pokdownload
>
> To build it on Debian you need:
> GCC, binutils, perl, libxml-xpath-perl (the XML::XPath::XMLParser),
> libxml-libxml-perl (the XML::LibXML Perl module), mtools (optional),
> qemu, make.
>

Do you need qemu to build it ?

> For ppc and sparc you need to build the cross toolchain described here:
> http://pok.safety-critical.net/wiki

Do you need those specific versions of GCC ? They look a little old.

I see for the sparc is a sparc-elf target. I also see --with-newlib is 
present but the wiki page does not indicate a version or how this is 
handled.

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

> This provides all information
> for the interaction with POK to RTEMS.

Does this include headers ?

> Then I just build the RTEMS
> samples with --enable-paravirt for virtualpok and wait for it to fail at
> the timertests (no timer implemented).
> To execute the code, I need to copy for example hello.exe to a POK
> program, place it in a partition and relink the POK binary to pull the
> 'foreign' binary into POK's final system binary.
> It's then tested with qemu.

That will be a interesting challenge to add into our testing framework.

Is the qemu the standard one or does pok have extra patches ?

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

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

Chris