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:
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 ?
No. Only as a test platform.
Great. One less dependence to supporting building.
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.
No, I used gcc 4.8.0.
Great.
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.
I only followed these steps and it worked. I guess it just concerns the
files delivered together with gcc.
Ok. I will have a play.
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.
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 ?
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 ?
No. Standard Qemu is used.
Great.
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.
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
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
