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

Reply via email to