On Fri, Mar 7, 2014 at 4:44 AM, Philipp Eppelt
<philipp.epp...@mailbox.tu-dresden.de> wrote:
> On 03/06/2014 06:58 PM, Gedare Bloom wrote:
>> Hi Philipp,
>>
>> On Wed, Mar 5, 2014 at 3:48 AM, Philipp Eppelt
>> <philipp.epp...@mailbox.tu-dresden.de> wrote:
>>> Hi,
>>>
>>> as of now it looks like we have a student picking up my work from last
>>> year. While the patches for the --enable-paravirt configuration option
>>> went upstream, the virtualpok BSP for i386 still has open issues.
>>>
>>> I reviewed the discussion we had in December and January on the
>>> virtualpok BSP for i386. We ended with the following two issues:
>>>
>>> * Extension of --enable-paravirt to pass along /path/to/libpart.a (in POK)
>>> * How can we ensure that the POK and RTEMS virt.layer header files don't
>>> diverge.
>>>
>> Thanks for pulling these issues out.
>>
>>> The first point is clear. The second is complicated. From the design
>>> point of view, the BSP should communicate transparently with the host.
>>> This transparency is provided via the two header files
>>> virtualizationlayer{cpu|bsp}.h . The missing implementation has to be
>>> provided by the host, otherwise the BSP can't be build. Which is quite
>>> okay, as this failure is exactly telling you what is missing.
>>>
>>> However, if our or the host side is changing and the changes aren't
>>> propagated to the other side, it is difficult to track and find the error.
>>> Can we build in some checks?
>>> I don't think one could force POK to check for updates at compile time.
>>> However, I can imagine a script being build after
>>> --enable-paravirt=/path/to/libpart.a is configured, which determines the
>>> correct location of virtualizationlayer{cpu|bsp}.h in POK and diff these
>>> files with the BSP local definition.
>>>
>>> e.g.:
>>> ret = diff virtualpok/include/virtualizationlayerbsp.h
>>> /path/to/libpart.a/../../../virtualizationlayerbsp.h
>>> if( ret != 0 ) print ERROR
>>> ***
>>> Can we integrate such a script into a generated makefile? Or is it
>>> sufficient to just provide this script and describe it in the BSP's readme?
>>>
>> I'm not satisfied with this solution. It assumes the pok sources are
>> the same as the ones used to build the libpart.a. Can the required
>> header files from pok be packaged with the libpart.a?
> The header files are part of RTEMS's virtualization layer, upon which
> the RTEMS BSP builds.
> With the --enable-paravirt option, RTEMS should grab libpart.a directly
> from the host's build tree. I don't understand, where and how you want
> to package the header files. Into the library file?
>
When you say host's build tree, are you referring to POK? This
dependency to the build tree of another project is suspicious to me.>> Some other options would be nice to consider. > > How much information does libpart.a already contain? Isn't the linker > objecting, if the function declaration differs from it's implementation > provided via libpart.a? > Let's say the declaration in virtualizationlayerbsp.h is: > void sample(int parm); > > and the implementation in libpart.a is: > void sample(unsigned long parm); > > Shouldn't the linker raise an error in this case? > I don't know, does it? > Cheers, > Philipp > >>> >>> Another question is if the linker is checking the full header? The >>> function name and all parameter types? Wouldn't this be sufficient to >>> alert the user of inconsistencies? >>> >>> >>> Automated testing is a third issue. But I'd like to postpone this, until >>> we actually have something that can be tested. >>> >>> >>> Cheers, >>> Philipp > _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
