GSoC RTEMS compilation issues

[Gedare Bloom]

On Wed, Jun 20, 2012 at 3:21 PM, WL <jolkaczad at gmail.com> wrote:
> I've read the document before and it helps a lot, but some things
> remain unclear since no piece of documentation can describe everything
> in detail.
>
> For example, what I understand is that the cpukit/score/cpu/* and
> /c/src/lib/libbsp/* directories for the appropriate processor are
> decided according to the target of the used compiler passed as a
> parameter to the configure script. My target is i386, but I don't want
> to use the cpukit/score/cpu/i386 functions (which are trying to get
> compiled and linked) since none of them make sense for the hypervisor.
> How do I go around this without making significant changes to the
> default RTEMS tree?

I can think of two possible ways forward off the top of my head.

1. Introduce a new "virtual" architecture. This would add
cpukit/score/cpu/virtual or something similar. The virtual
architecture would implement its context switch and ISR handling as
hypercalls. How to deal with choice of compiler and bsp would
remain...

2. Modify i386 architecture so that it does not execute privileged
code in cpukit/score/cpu/i386. I don't know if there is a multilib
variant that can be used to determine whether to use privileged code
or hypercalls. If there is no multilib-safe way to do it then I guess
you would have to move the hypercalls and privileged code to
c/src/lib/libcpu/i386 and then split the cases to use hypercalls for
paravirtualized i386 and regular code for i386 hw.

I have no idea if either of these is best (or which is better than the other).

-Gedare