On 05/15/2013 03:55 PM, Gedare Bloom wrote:
On Tue, May 14, 2013 at 11:55 AM, Philipp Eppelt
<[email protected]> wrote:
Hi,
I looked into the libcpu/sh dir to understand how the split of the CPU code
between score/cpu and libcpu/ works.
My approach for the i386 arch brings some changes to existing files:
* score/i386/rtems/score/cpu.h
* score/i386/cpu.c
* score/i386/rtems/score/interrupts.h
The list of functions, sensitive for a virtualization environment is rather
short (up until now):
* _CPU_ISR_Set_level (cpu.h)
* _CPU_Fatal_halt (cpu.h)
* _CPU_Thread_Idle_body (cpu.c)
* everything in interrupt.h
For a full and up to date list, check [0].
I want to introduce new directories containing the right versions for the
above mentioned functions:
* libcpu/i386/virt-pok
* libcpu/i386/{native|hw|nonvirt|..}
Why "virt-pok" and not just "virt" or "virtual"?
Probably the other side (native/hw/nonvirt) can just be called
"shared/score". And you would put the virtualized functionality in the
"virt-pok/score".
I would refrain from calling it shared/, as it would imply shared
functionality with virtual/. At least that my understanding of the usage
in all other parts of the system.
Maybe native is the best description as it opposes virtual.
*libcpu/i386/virtual
*libcpu/i386/native
Which part do I need to explain in more detail?
Probably the justification for which code is identified as
sensitive/privileged, and what is not.
The mentioned functions contain privileged instructions: hlt, cli, sti
These functions cannot be executed in a virtual environment and must be
replaced with environment specific function calls.
Regards,
Philipp
_______________________________________________
rtems-devel mailing list
[email protected]
http://www.rtems.org/mailman/listinfo/rtems-devel