Sylvestre Gallon wrote: > It's not that I am not up to it or that I think that I am not able to > do it, but I will probably need more help and more mentoring to > implement a kvm-like subsystem than to port dragonflybsd to xen.
Aggelos Economopoulos wrote:
What kind of changes would you have to make to our core kernel code for Xen support?
Was thinking about this again myself - as someone who has mucked around with merging various things into vkernel / from other os's -
(assuming you are new to developing on any of the BSD-like systems or similar)
you might simply take a look at what it would take to make either possible before you commit to one approach or the other -
I'd suggest first investigating how the dragonfly VKERNEL works (as you'll need to be adding a new 'architecture' anyhow - and VKERNEL is a good example of a quasi-architecture that is part 'real' (e.g. i386), and partially 'virtual' (e.g. vkernel's supporting vmspace) - so it would be useful to know for either approach.
After you get some kind of understanding of this, perhaps adding some silly little change to get a hang of the build process, etc,
perhaps take a look at the NetBSD Xen implementation (as I'd suspect it is the best place to start for a port), to see if this approach still makes sense..
In the process you'll be able to see how things might work and decide on the best approach / pluses and minuses - one thing I can think of offhand is that Xen might need more driver work, whereas something native might be able to be 'kludged' around .. with xen, you'll need a host platform and also a dragonfly dev system (so two build systems / source trees to deal with/learn), whereas dragonfly would be one, etc.
of course there are things in the other direction as well but as noted before I am biased :)
other side effect of this is at the end of this, you'll know what you're getting into - and also have a dev system in place!
anyhow, good luck with your investigation and look forward to hearing about your progress in either case..
- Chris
