Paravirtualization project - GSOC 2013

[Philipp Eppelt]

Hi,

yes, that's better. This way we just need to introduce one new 
configuration parameter and don't have to touch the others.

I would prefer --enable-virt over --enable-bsp="virt", because the BSP 
name should stay the same, nonetheless we are running virtually.

What's your opinion on the directory structure?
c/src/lib/libbsp/virt/<bsp_name>
c/src/lib/libbsp/virt/share
cpukit/score/cpu/virt/<cpu_name>
cpukit/score/cpu/virt/share


Regards,
Philipp


On 04/14/2013 11:54 PM, Cláudio Silva wrote:
> Hi,
>
> I think developing an interface really independent from the hardware
> will be difficult. You will end up with some hardware dependent code.
> Nevertheless, the inclusion of a virtualization BSP on the tree has to
> be better analyzed and discussed, due to the constraints on how the BSPs
> and CPU targets are handled.
>   I would prefer to maintain the target option and add something like
> --enable-virt ou --enable-bsp="virt"; We probably want to minimize the
> virtualization interface and keep it close to the processor as possible.
> Hence, you will probably end up with something which is partially bound
> to a given CPU architecture.
>
>
> Cláudio
>
>
> On Sat, Apr 13, 2013 at 5:47 PM, Philipp Eppelt
> <philipp.eppelt at mailbox.tu-dresden.de
> <mailto:philipp.eppelt at mailbox.tu-dresden.de>> wrote:
>
>     Hi,
>
>     I was thinking about the CPU issue mentioned in the last years ARINC
>     653 project.
>
>     How can a BSP be written, that has no corresponding CPU?
>     To be precise:
>              c/src/lib/libbsp/paraVirt/
>              without cpukit/score/cpu/paraVirt/
>
>     This should ease the usage across different CPUs. So the amount of
>     platform dependent code is reduced.
>
>     But another idea crossed my mind. Why not use a approach similar to
>     the no_cpu?
>     This would mean to provide a virtual CPU model with a manual
>     describing how to fill in the CPU dependent code.
>     Also, introduce a x86_virt (sparc_virt, sparc64_virt and so on) CPU
>     model.
>     To prevent clobbering the cpukit/score/cpu/ directory they all go
>     into cpukit/score/cpu/virtCPU/ and an additional configuration
>     parameter should specify the cpu used.
>     So instead of --target=i386-rtems4.11 we use --target=virt-rtems4.11
>     --enableVirtualCPU=i386. (like --enableBSP=)
>     And the platform independent stuff goes into
>     cpukit/score/cpu/virtCPU/__shared
>
>
>     What do you think? Is this feasible?
>
>     Regards,
>     Philipp
>
>
>
>
>
>
>
>
>
>
>     _________________________________________________
>     rtems-users mailing list
>     rtems-users at rtems.org <mailto:rtems-users at rtems.org>
>     http://www.rtems.org/mailman/__listinfo/rtems-users
>     <http://www.rtems.org/mailman/listinfo/rtems-users>
>
>