Paravirtualization project - GSOC 2013

[Philipp Eppelt]

On 04/16/2013 03:35 AM, Chris Johns wrote:
> Philipp Eppelt wrote:
>>
>> 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
>
> I have not followed all of this discussion closely. I would have
> expected a virtual BSP must still run on a architecture even with code
> shared across different arch so a directory structure could be ...
>
>   c/src/lib/libbsp/<arch>/<bsp_name>
>   c/src/lib/libbsp/<arch>/share/virt
>   c/src/lib/libbsp/share/virt
>   cpukit/score/cpu/<cpu_name>/virt
>
> No idea about this one ..
>
>   cpukit/score/cpu/virt/share
>
> Chris
Hi,

if I add a new virtual BSP to an existing architecture, I use the 
corresponding cpu code in cpukit/score/cpu. So I would have to add code 
in every architecture, for example by adding '#ifdef VIRT'.

But I also could create a new directory for all the ported virtual 
BSPs/CPUs. It wouldn't mix virtual and non-virtual BSPs, I don't clutter 
up existing ones and it would be easy to see, which BSPs already are 
virtualization capable.
Additionally, I could introduce a shared directory in 
cpukit/score/cpu/virt for include files, e.g. containing cli/sti 
replacement functions.

With the --enable-virt flag the autoconf files can be notifed about the 
different directory structure.
I spotted a mistake in my proposed structure. It should be:

c/src/lib/libbsp/virt/<arch>/<bsp_name>

So the same structure, only with /virt/ added after /libbsp.

However, I don't know the autoconf process in detail. That's why I'm 
asking if this is a feasible approach.


Regards,
Philipp