GSoC RTEMS compilation issues

Joel Sherrill joel.sherrill at
Thu Jun 21 13:39:47 UTC 2012

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,
> Regards,
> Cláudio
> On Thu, Jun 21, 2012 at 9:47 AM, Ralf Corsepius
> <ralf.corsepius at>  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-devel mailing list
> rtems-devel at

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

More information about the devel mailing list