GSoC RTEMS compilation issues

[Joel Sherrill]

On 06/20/2012 03:04 PM, Gedare Bloom wrote:
> 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?
What in there doesn't make sense? The interrupt vectoring
code is not in score on i386.  All I can think of is sti/cli for
enable/disable interrupts.
> 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...
On the surface, this sounds good but the target name
implies the CPU, tools, etc.  If you have "virtual" then
you may have to compile the same virtualized code
for powerpc, x86, arm, sparc, etc. How would this happen?

Adding a --enable-virtualized may make sense if the changes
can be restricted. You may not be able to build every BSP
in that configuration. But that is OK I guess.


> 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.
If it isn't much code, this is appealing but cli/sti are at the top of 
the list
and those need to be inlined as a general rule across all targets.

How much code in score/cpu/i386 is offensive?

There is likely a core set of methods which are not appropriate in
paravirtualized environments on all target.

--enable-paravirtualized may be the best option.


> I have no idea if either of these is best (or which is better than the other).
>
> -Gedare
> _______________________________________________
> 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