* Separate out the test runner from the results collector/aggregator/controller so that you can run the test runner on a VM or vkernel, and collect the results on a different system. That way, if the system under test crashes, the tests can continue.

* Create necessary infrastructure, including provisioning, to be able to spin up VMs with DragonFly for testing, especially kernel testing. A first step would be to get this to work with spinning up vkernels.

+* Add support for per-testcase manifests instead of having to put everything in the runlist

+* Allow testcases to specify a list of artifacts that should be kept

* Integrate all tests we have into dfregress

* Add an html output generator like dfr2text. I have a started one laying around somewhere.

+DragonFly has no efficient solution for running other operating systems as guests.

+[Bhyve](http://bhyve.org/) is virtual machine manager for FreeBSD similar to the Linux KVM. This would be a big step forward for DragonFlyBSD, as it would allow us to run DragonFly on native hardware in situations where also Linux (or other operating systems) is required. IMHO, this would also reduce/eliminate the need for Linux 64-bit compatibility.

+

+Meta information:

+

+* Prerequisites: C, heavy kernel knowledge

+* Difficulty: Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+---

+

+##### Support DragonFly on bhyve - The BSD Hypervisor

+

+DragonFly needs a new loader to run on [Bhyve](http://bhyve.org/)

+

+Meta information:

+

+* Prerequisites: C, heavy kernel knowledge

+* Difficulty: Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+---

+

+##### Port VirtualBox

+DragonFly has no efficient solution for running other operating systems as guests. VirtualBox depends on

+a kernel module. Port this from FreeBSD.

+

+Meta information:

+

+* Prerequisites: C, Kernel knowledge

+* Difficulty: Medium-Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+---

+

+##### Improve DragonFly as a VirtualBox guest

+When running DragonFly under VirtualBox, you don't have good support for graphics and also the clipboard is not working between host and guest. Port the virtualbox guest extensions to DragonFly.

+

+Meta information:

+

+* Prerequisites: C, Kernel knowledge

+* Difficulty: Medium-Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+---

+

+##### Support KVM

+Add a KVM-compatible API to DragonFly, to be able to run qemu-kvm natively. This requires a fair bit of prior investigation as part of the proposal.

+

+This could be based on a port of bhyve (see the bhyve project on this page), with an added compatibility API for KVM.

+

+[https://www.kernel.org/doc/Documentation/virtual/kvm/api.txt]

+

+Meta information:

+

+* Prerequisites: C, Kernel knowledge

+* Difficulty: Very Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+

+---

+

+

+##### Tickless Kernel

+Make the DragonFly kernel tickless.

+

+Meta information:

+

+* Prerequisites: C, Kernel knowledge

+* Difficulty: Medium-Hard

+* Contact point: kernel@lists.dragonflybsd.org

+

+---

+

+##### Experiment with Rust in the kernel

+[Rust](http://www.rust-lang.org) is a safetly-oriented language in the same leage as C++ but without many of it's short-comings. It doesn't depend on a GC and can be used for very low-level tasks as well as high-level code. It is heavily developed by the Mozilla foundation.

+

+The GSoC project would consist of being able to write a simple kernel module in Rust and access some of the kernel API (kmalloc, etc.). It also includes bootstrapping Rust to DragonFly.

+

+What can be accomplished with Rust in the kernel? What would be the advantages and what the disadvantages? For example how could the device hierarchy be represented in Rust? Implementing a simple device driver. How can existing APIs be represented in Rust using traits? How could C call Rust code?

+How fast can be boot? Where (in which subsystems) is most time spend. What can we do to boot faster?

+

+* Research source of delays in boot process, keyboard init, scsi?

+* Better thread some hardware init, for example USB?

+* Perhaps look to see how Linux can boot in one second, better pci scan code?

+* "Some kernel work made it possible to do asynchronous initialization of some subsystems. For example, the modified kernel starts the Advanced Host Controller Interface (AHCI) initialization, to handle storage, at the same time as the Universal Host Controller Interface (UHCI), in order to handle USB" - http://lwn.net/Articles/299483/