-Have a look at our SoC pages from [[2008|/docs/developer/GoogleSoC2008/]], [[2009|/docs/developer/gsoc2009/]], [[2010|/docs/developer/gsoc2010/]] and [[2011|/docs/developer/gsoc2011/]] to get an overview about prior year's projects.

+Have a look at our SoC pages from [[2008|/docs/developer/GoogleSoC2008/]], [[2009|/docs/developer/gsoc2009/]], [[2010|/docs/developer/gsoc2010/]], [[2011|/docs/developer/gsoc2011/]], and [[2012|/docs/developer/gsoc2012/]], to get an overview about prior year's projects.

For more details on Google's Summer of Code: [Google's SoC page](http://socghop.appspot.com/)

-DragonFly's version of the pf firewall was brought in from OpenBSD 4.7. FreeBSD imported the pf from OpenBSD 4.8 and has significant enhanced the SMP performance of the firewall. Port the FreeBSD version of pf.

+DragonFly's version of the pf firewall was brought in from OpenBSD 4.7. FreeBSD imported the pf from OpenBSD 4.8 and has significantly enhanced the SMP performance of the firewall. Port the FreeBSD version of pf.

+DragonFly is currently limited to 63 CPU cores. Servers with more core than that are becoming sort of available or even potentially affordable. Supporting a number of cores greater than 63 is the first step in really testing SMP.

+* Add a hammer2 utility command and associated ioctl to set the encryption mode on a directory, to be inherited by any new files or subdirectories created therein.

+

+* Implement one encryption method. Encryption meta-data space is available in the blockref, usually around 192 bits, which can be used to specify e.g. a public key, salt, IV, and/or encryption chaining through the filesystem topology. Actual physical blocks must be encrypted in-place (1:1).

+* hammer2 implements a fully set-associative indirect block table with dynamic radix, which means that the entries in an indirect block table have a lot of flexibility, including the ability to have redundant entries representing the same block.

+

+* Implement hammer2's copies feature which allows one to configure multiple volumes and to specify that more than one copy of the filesystem topology be maintained. This requires both a realtime piece to handle filesystem modifications in progress, and a batch piece to tie-up loose ends. for a GSOC the batch piece is the easiest to implement for writing purposes, with a realtime piece for reading (but not writing, which would be much more difficult). The batch piece would simply traverse the filesystem looking for missing copies and construct the missing copies in batch or semi-real-time.

+

+* Such an implementation would allow HAMMER2 to operate with redundant hard drives and for hard drives to be ejected and added (within reason) on a live system.

+DragonFly has a simple regression testing framework, dfregress(8) and tbridge(9), that supports testing both userland and kernel modules.

+Potential work to be done:

+

+* 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/