On Wed, May 15, 2013 at 1:29 PM, Philipp Eppelt <[email protected]> wrote: > > > 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 > OK this might be good enough. The "shared/" subdirectory is used as an optional shared in libbsp, but since shared/ exists in some of the libcpu/ARCH directories, it will be better to provide a new name like "native" or whatever we finally set on.
> > >>> 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. > Yes I know, we just need to document the set of instructions (per architecture) somewhere sensible. > > Regards, > Philipp _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
