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

[Gedare Bloom]

On Wed, May 21, 2014 at 6:24 PM, Chris Johns <chrisj at rtems.org> wrote:
> 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.
>
I'd like to find an answer to this problem about linking to external
projects for the sake of our POK efforts.

-Gedare