New configure option RTEMS_VIRTUAL

[Gedare Bloom]

On Tue, Sep 17, 2013 at 8:49 AM, Philipp Eppelt
<philipp.eppelt at mailbox.tu-dresden.de> wrote:
> Hi,
>
> in my GSOC project I aim for a virtualized version of RTEMS. I develop
> it for the i386 target and moved the interrupt.h code to libcpu to be
> included dependent on the CPU target. So a native cpu still gets the
> normal code, but the virtual one will call the virtualization layer.
>
> This leads to an #include<libcpu/interrupt.h> in
> cpukit/score/cpu/i386/rtems/score/cpu.h. I was told it is not allowed to
> include files in cpukit from outside cpukit.
> As this is performance critical code the interrupt macros can't be
> replaced with function, which would enable me to declare the functions
> in cpukit and implement them in libcpu.
>
> The only satisfying way to compile the interrupt code dependent on
> native or virtual environment is to introduce a configuration option
> similar to RTEMS_SMP and RTEMS_MULTIPROCESSING:
>
> RTEMS_HYPERVISOR or RTEMS_VIRTUAL
>
I'm preferential to this high-level switch. I would avoid
RTEMS_HYPERVISOR, because RTEMS is not the hypervisor, it is the guest
VM.

>
> Other options:
> :Introduce a new CPU target:
> Besides i386 a new CPU i386-virtual could be introduced. This adds a lot
> of duplicated code. The only difference would be 160 lines of code.
>
>
> In the future this option can be used for other projects virtualizing
> RTEMS on top of some hypervisor with any target CPU.
>
>
> Do you have other ideas?
> What do you think about this?
>
>
> Cheers,
> Philipp
> _______________________________________________
> rtems-devel mailing list
> rtems-devel at rtems.org
> http://www.rtems.org/mailman/listinfo/rtems-devel