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". > > To get this into the toolchain: > * Introduce a conditional called 'virt-pok' in configure.ac > * Branch on this conditional in Makefile.am > Yep. > > > As just a small portion of cpu.h is affected, does it make sense to split > this file? I think so. Documentation shall have to be added in a few places. > 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. > Do you know of any traps, that I might run into? There may be some doubts about performance if some thing that is a macro or inline routine turns into a function call. Then we will need to evaluate the performance overhead for the non-virtualized version. > What do you think of this? > Is there a chance to get this change upstream? Otherwise I have to find a > more convenient approach to solve this. > I think so, but it depends a little on the performance overhead. Probably it will be fine... -Gedare > > Regards, > Philipp > > > [0] > http://wiki.rtems.org/wiki/index.php/GSOC_2013_-_Paravirtualization_of_RTEMS#libcpu.2Fscore_split > _______________________________________________ > rtems-devel mailing list > [email protected] > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list [email protected] http://www.rtems.org/mailman/listinfo/rtems-devel
