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

[Philipp Eppelt]

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?

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

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