GSoC RTEMS compilation issues

[WL]

On Thu, Jun 21, 2012 at 5:13 AM, Joel Sherrill
<joel.sherrill at oarcorp.com> wrote:
> 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?
Actually, all of it. The code relates to exception handling, cpu
initialization and as mentioned - cli, sti. For the hypervisor, can
these be moved to the c/src/lib/libcpu/i386/pok and exclude the
score/cpu/i386 altogether depending on --enable-virtualized?

>
> 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
>
>