vkernel & GSoC, some questions
kris at FreeBSD.org
Sun Mar 16 13:26:22 UTC 2008
Jordan Gordeev wrote:
> I am a student who considers applying for Google's Summer of Code
> One of my ideas for a GSoC project has the following synopsis:
> Add virtual kernel (vkernel) support to FreeBSD for the i386 and
> amd64 architectures.
> The vkernel support in question is the one found in DragonFlyBSD.
> I wonder if vkernel support would have its place among the myriad of
> virtualisation technologies, and if it would aid kernel hackers in their
> kernel development work.
> I also wonder if anybody would be interested in mentoring this.
There are some important things to be aware of with Dragonfly's vkernel.
Firstly, while Matt brought it to the point where it works to the extent
of booting, being able to recompile kernels, etc, it was never optimized
for performance. Dragonfly vkernels are *slow*, even relative to
dragonfly non-vkernels which are already much slower than FreeBSD
kernels across the board.
In this sense it is not a complete project, and what remains to be done
is the harder part of the work. It has also not been seriously
stress-tested (in part because it is not production quality, but also
because it has few users), so there may be a lot of bug fixing required
to stabilize the code.
Secondly, I don't know to what extent the vkernel work is
multi-processor ready, but given that SMP support has also not been a
priority for dragonfly there may well be large amounts of SMP work
needed to integrate with FreeBSD. Any multi-processor synchronization
present would likely have to be reimplemented for FreeBSD anyway due to
the different architectural models.
None of these issues are being actively worked on in dragonfly, as far
as I know.
Finally, the way vkernels were implemented in dragonfly was *very*
disruptive to the kernel source (lots of function renaming etc), so it
is likely that this would also have to be completely reimplemented in a
The bottom line is that while vkernel is an interesting beginning of a
project, it is not a complete piece of code that is suitable for porting
to FreeBSD in its present form, and that doesn't seem likely to change
in the forseeable future.
More information about the freebsd-hackers