On 22/05/2014 12:15 am, Joel Sherrill wrote:
On 5/21/2014 8:54 AM, Gedare Bloom wrote:
On Wed, May 21, 2014 at 4:04 AM, Christian Mauderer
<christian.maude...@embedded-brains.de> wrote:
First of all: Thanks for your comments. You will find answers below.
Rather than resetting this discussion, there is some below and a comment on
the README and general use here.
The README says there are two environment variables. Why not configure
time parameters? I thought that was how the other paravirtualization work
was doing it.
Environment variables for configuration control are dangerous.
+#ifdef RTEMS_PARAVIRT_XTRATUM
+#include <xm.h>
What is this header file? I don't see it in the commit, is it part of
the installed XtratuM?
That is correct. It's part of XtratuM. Is there some preferred way of
marking such headers?
Not that I know of. We have discussed a similar issue with the POK
paravirtualization project. The problem is to allow external code
linking to RTEMS. The design should be considered carefully and
probably discussed in a separate thread.
[...]
Agreed. But I don't see any practical solution to this other than to assume
that the interface file is provided by the virtualization engine. They
own it.
If the virtualization software changes its interface, then the .h would
naturally update that way.
We also have the issue of any library code the virtualization engine
needs the BSP/app to link with. We had concerns that it may not
be in the right format.
I may be cynical here but I think the only practical solution is to
assume that the virtualization engine's .h along with .o/.a files
the BSP must link with are externally provided. This means that
the BSP must account for them being in an incompatible format
and at least provide a manual procedure or script to deal with
that once.
I do not think it is as simple as this and depends on the code in these
libraries and the virtualization ABI. As expressed with POK I feel RTEMS
working at the lowest level reduces the long term maintenance overhead
because this layer should be defined and stable. I think building code
with anything other than the RTEMS compiler is not a good idea. It may
work but that is just luck.
Since xtratum is GPL v2,
It says it is GPLv3 on the download page and further states "Partitions
are GPL execution environments." and this is something we cannot accept.
It makes testing in our test servers an issue because the person
responsible for running the tests needs to make sure all the licenses
are valid and I will not do that and I suspect Amar will not either.
I am sorry but I do not see how we can support this VM within RTEMS.
Chris
_______________________________________________
rtems-devel mailing list
rtems-devel@rtems.org
http://www.rtems.org/mailman/listinfo/rtems-devel
