Done in GSoC 2010

diff --git a/docs/developer/gsoc2010/index.mdwn b/docs/developer/gsoc2010/index.mdwn
index 42b7d91..bed4d57 100644 (file)
--- a/docs/developer/gsoc2010/index.mdwn
+++ b/docs/developer/gsoc2010/index.mdwn
@@ -108,18 +108,6 @@ Meta information:
 
 ---
 
-##### Graphics Kernel Memory Manager Support ( GEM )
-* Support dealing with graphics NUMA in kernel space for modern graphics hardware
-* http://en.wikipedia.org/wiki/Graphics_Execution_Manager
-
-Meta information:
-
-* Prerequisites: C, knowledge of modern computer graphics system architecture
-* Difficulty: Moderate
-* Contact point: kernel@crater.dragonflybsd.org
-
----
-
 ##### Make DragonFly NUMA-aware 
 
 * Parse related ACPI tables 
@@ -128,7 +116,7 @@ Meta information:
 [ACPI SLIT parser](http://mail-index.netbsd.org/tech-kern/2009/11/23/msg006518.html)
 [ACPI SRAT parser](http://mail-index.netbsd.org/tech-kern/2009/11/23/msg006517.html)
 [NetBSD NUMA diff](http://www.netbsd.org/~cegger/numa2.diff)
-[NetBSD NUMA x86 diff](http://www.netbsd.org/~cegger/numa_x86.diff)
+[NetBSD NUMA x86 diff](http://www.netbsd.org/~cegger/numa_x86.diff) (These patches now in NetBSD tree)
 
 Meta information:
 
@@ -138,56 +126,6 @@ Meta information:
 
 ---
 
-##### 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.
-
-Meta information:
-
-* Prerequisites: C, elementary OS internals
-* Difficulty: Medium
-* Contact point: Aggelos Economopoulos <aoiko@cc.ece.ntua.gr>
-
----
-
 ##### Port DragonFly to Xen platform
 
 Meta information: