On Tue, Sep 17, 2013 at 8:49 AM, Philipp Eppelt <philipp.epp...@mailbox.tu-dresden.de> wrote: > Hi, > > in my GSOC project I aim for a virtualized version of RTEMS. I develop > it for the i386 target and moved the interrupt.h code to libcpu to be > included dependent on the CPU target. So a native cpu still gets the > normal code, but the virtual one will call the virtualization layer. > > This leads to an #include<libcpu/interrupt.h> in > cpukit/score/cpu/i386/rtems/score/cpu.h. I was told it is not allowed to > include files in cpukit from outside cpukit. > As this is performance critical code the interrupt macros can't be > replaced with function, which would enable me to declare the functions > in cpukit and implement them in libcpu. > > The only satisfying way to compile the interrupt code dependent on > native or virtual environment is to introduce a configuration option > similar to RTEMS_SMP and RTEMS_MULTIPROCESSING: > > RTEMS_HYPERVISOR or RTEMS_VIRTUAL > I'm preferential to this high-level switch. I would avoid RTEMS_HYPERVISOR, because RTEMS is not the hypervisor, it is the guest VM.
> > Other options: > :Introduce a new CPU target: > Besides i386 a new CPU i386-virtual could be introduced. This adds a lot > of duplicated code. The only difference would be 160 lines of code. > > > In the future this option can be used for other projects virtualizing > RTEMS on top of some hypervisor with any target CPU. > > > Do you have other ideas? > What do you think about this? > > > Cheers, > Philipp > _______________________________________________ > rtems-devel mailing list > rtems-devel@rtems.org > http://www.rtems.org/mailman/listinfo/rtems-devel _______________________________________________ rtems-devel mailing list rtems-devel@rtems.org http://www.rtems.org/mailman/listinfo/rtems-devel
