GSoC RTEMS compilation issues
joel.sherrill at OARcorp.com
Wed Jun 20 21:13:59 UTC 2012
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
> 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
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
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).
> rtems-devel mailing list
> rtems-devel at rtems.org
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
More information about the devel