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 _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
