On Wed, May 21, 2014 at 6:24 PM, Chris Johns <chr...@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.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. > I'd like to find an answer to this problem about linking to external projects for the sake of our POK efforts.
-Gedare _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
