On 8/03/2014 12:38 am, Philipp Eppelt wrote:
For the next design, I would be very interested to hear the expectations and requirements up front.
The ideal situation is POK being built without any specific detail of RTEMS and RTEMS POK support is implemented for a supported architecture and a BSP within the architecture.
We should treat POK as a binary black box when looking from RTEMS. RTEMS makes calls to a specific and agreed interface and POK responds in a defined manner.
This approach means the tools and options used to build POK and RTEMS can vary independently. The only requirement is the resulting code generated meets the ABI.
When I mean ABI I mean the machine level.
So we don't have to go through this discussion again.
I agree.
Questions like: Are we allowed to have dependencies to the host(POK)?
Yes at an ABI level that defines the calls to POK. RTEMS needs to contain code that implements these calls.
Which dependencies are allowed?
Consider how we would need to maintain the continuous integration server so this can be tested.
We need a suitable POK version and we would assume this is a stable released version that is approved for RTEMS. There may be RTEMS specific patches as version skew between the upstream POK and RTEMS move around. POK is considered stable and should not vary in the short to medium term. The POK build system would need to support the RTEMS server farm operating system which is FreeBSD. You can consider the POK dependency as being similar to the tools for RTEMS and how they are handled. If POK needs specific tools or other libraries these dependences would need to be added to the list. I would not expect to be building POK each time we build and test RTEMS.
If the interface code which is currently called libpart.a was in RTEMS we would have no further dependences. The way the code is built and how it is built is contained in RTEMS so a change in build flags would effect the BSP, RTEMS and this code. If this code is separate from POK and RTEMS we would need to build this code with the tool set we would be using to build RTEMS and the same flags (or close to the same flags). We would also need to manage the dependence between the build flags used for both libraries. Some architectures have flags that vary the ABI, eg hard vs soft float. If this code resides in POK we would have RTEMS dependent on POK and POK dependent on RTEMS and that is not my preferred path.
Which dependency checks need to be in place?
The ABI version in POK and the version in RTEMS. I suspect this would be a runtime check. It the libpart.a is separate another check for its version would be needed and maybe the flags used to build it (I have no idea how you would do this).
If the ABI changes we need a new version number to check and a new POK and updated code in RTEMS (if libpart.a was in RTEMS). If the RTEMS build flags or new tools breaks the ABI on the RTEMS side that is a bug and our testing should show this. A new POK needs to have been tested against a known RTEMS version and so the ABI tested before it is released and we use it for our testing.
I hope this helps. Chris _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
