GSoC RTEMS compilation issues

[Joel Sherrill]

On 06/21/2012 04:03 AM, Cláudio Silva wrote:
>> Counterquestion: Which steps are required to make a BSP "para-virtualized"
>> and how is such a BSP different from an "ordinary BSP".
> I think the question is that the functions available on
> cpukit/score/cpu/* are not required for a paravirtualized BSP (e.g.
> Context_Switch, Interrupt Handling).
>
> You can maybe protect those files with an "#ifdef
> BSP_PROVIDES_CONTEXT_SWITCH" or something like that.
> If these functions can be cpu independent system calls to the
> hypervisor maybe defining an cpukit/score/cpu/paravirt is the best
> option. You can think of it as an "virtual CPU" provided by the
> hypervisor that is independent from the real architecture.
Having SuperCore code depend on any BSP specific information
is strictly against the rules for what goes in score.

As Julien and I have pointed out, there are a handful of things
that must be considered and balanced:

+ paravirtualized may or may not have access to protected
     mode instructions (e.g. enable/disable interrupts) or certain
     registers (e.g. msr on PowerPC). On PPC, in user mode, you
     can't tell if FPU (or Altivec?) is enabled.
+ target hardware is fundamentally the same whether
     virtualized or not. This means you really want to reuse:
      - toolset
      - score/cpu/XXX where possible
      - BSP where possible
    For example, Pok has three configurations -- sparc, x86, and PPC.
    They have used the same qemu configurations to test those that
    we have.
+ IRQ management is likely different
+ letting RTEMS know of time passage is likely different
+ hypervisor may or may not provide thread context switch

The particular set of things which are not OK when paravirtualized
may be different depending on the target architecture.

At some level, this is similar to the old POSIX port of RTEMS but
is much closer to bare hardware. But the "port/bsp" is not nearly
as divergent because the hardware really is the same. We just
have help and are protected from it.

This lead me to the configuration option switch. That lets the port
be the same, the toolset be the same and the code adapt as needed.
The build system can replace files or conditionally compile common
files. It is also uniform across targets.

Adding other targets breaks the nice rules we have on TARGET-tool,
etc.
> Regards,
> Cláudio
>
>
> On Thu, Jun 21, 2012 at 9:47 AM, Ralf Corsepius
> <ralf.corsepius at rtems.org>  wrote:
>> On 06/21/2012 10:09 AM, Julien Delange wrote:
>>>
>>> So that it builds and install the pc386 adapted for virtualisation.
>>
>> Counterquestion: Which steps are required to make a BSP "para-virtualized"
>> and how is such a BSP different from an "ordinary BSP".
>>
>> Ralf
>>
>> _______________________________________________
>> rtems-devel mailing list
>> rtems-devel at rtems.org
>> http://www.rtems.org/mailman/listinfo/rtems-devel
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel


-- 
Joel Sherrill, Ph.D.             Director of Research&   Development
joel.sherrill at OARcorp.com        On-Line Applications Research
Ask me about RTEMS: a free RTOS  Huntsville AL 35805
     Support Available             (256) 722-9985