[PATCH 2/2] bsps/sparc: Add XtratuM BSP.

[Chris Johns]

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.Mauderer at 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