Paravirtualization project - GSOC 2013

[Cláudio Silva]

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> 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
> http://www.rtems.org/mailman/**listinfo/rtems-users<http://www.rtems.org/mailman/listinfo/rtems-users>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.rtems.org/pipermail/users/attachments/20130414/4b7bbf4b/attachment-0001.html>