[PATCH] i386/virtualpok BSP, virtual BSP to be used with POK, build with enable-paravirt

[Philipp Eppelt]

On 03/07/2014 02:07 PM, Gedare Bloom wrote:
> On Fri, Mar 7, 2014 at 4:44 AM, Philipp Eppelt
> <philipp.eppelt at 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.eppelt at 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.
Yes, I'm talking about POK there.
To compile RTEMS for POK, we need libpart.a. This is produced during
compilation of a POK application.
Either we copy it to the RTEMS tree by hand or we pass the path to this
specific libpart.a to RTEMS via --enable-paravirt=/path/to/libpart.a.

The first was dismissed, as error prone and difficult to test.
So the second it is.


However, I think we can use this patch for this year's gsoc student, but
we need to rethink the design.
For the next design, I would be very interested to hear the expectations
and requirements up front.
So we don't have to go through this discussion again.

Questions like:
Are we allowed to have dependencies to the host(POK)?
Which dependencies are allowed?
Which dependency checks need to be in place?


> 
>>> 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?
I just made a test. GCC does complain if you have different declarations
in a header file and in the implementation, but if you provide an
implementation with a different 'parm' type via a library, no error is
raised.

> 
>> 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
>>