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

[Philipp Eppelt]

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.

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

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

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?
You can shortcut the compile step, by providing a 'libpart.a' to copy
into virtualpok/. Then it's just configure and compile.

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?

Cheers,
Philipp