(no commit message)
authorAggelosEconomopoulos <AggelosEconomopoulos@web>
Sun, 31 Jan 2010 11:34:21 +0000 (03:34 -0800)
committerCharlie <root@leaf.dragonflybsd.org>
Sun, 31 Jan 2010 11:34:21 +0000 (03:34 -0800)
docs/developer/gsoc2010/index.mdwn

index 58469bd..1e7a696 100644 (file)
@@ -35,4 +35,46 @@ For more details on Google's Summer of Code: [Google's SoC page](http://socghop.
 1. Data Integrity Framework Implementation
 * Something akin to what was done for Linux: http://oss.oracle.com/projects/data-integrity/
 
+1. Volume Management based on NetBSD's  port of LVM2
+
+    NetBSD reimplemented Linux's device mapper (currently only implementing
+the linear, zero and error targets; Linux has support for a variety of
+targets, including crypt, stripe, snap, multipath) as dm(4). Device mapper
+provides the functionality on which to implement volume management; NetBSD
+has imported LVM2 (which is GPL), but it is possible to create different
+tools for volume management (e.g. IBM's EVMS was also built on top of device
+mapper).
+
+    The goal of this project is to port both the kernel code, dm(4), and the
+LVM2 userspace libraries and tools from NetBSD. If time remains, the
+student should also implement a proof of concept "stripe" target or, for the
+more ambitious, a "crypt" target.
+
+    A possible roadmap for this project would be
+
+    1. Port the dm(4) code
+
+        This code uses proplib instead of binary ioctls for communicating with
+userspace. Either port proplib, or convert the code to use ioctls.
+
+    1. Port the userspace tools
+
+        Integrate the tools in our source tree using a separate vendor branch, as
+is normally done for contrib software (see development(7)). Make any
+DragonFlyBSD-specific changes necessary.
+
+    1. (Optional) Implement either a "stripe" target or a crypt target.
+
+        The stripe target must be designed with robustness and extensibility in
+mind, though it is not required to go all the way. It should be flexible
+enough to allow for different RAID level implementations (at least 0, 1
+and 5). Additionally, it should be possible to keep an internal (i.e. part
+of the volume) log to speed up resyncing and parity checking. Implementing
+those features would be ideal, but is not required.
+
+        The crypt target must allow for different ciphers and cipher parameters and
+should make use of our in-kernel crypto infrastructure. It is probably
+necessary to do the encryption asynchronously which will require extending
+the current infrastructure.
+
 (please add)