[[!toc levels=0]]
-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 [[2010|/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/)
##### Port pf firewall changes from FreeBSD
-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.
Meta information:
---
-##### Sync wireless infrastructure / drivers from FreeBSD
-
-Rui Paulo ported the wireless infrastructure and ath drivers to DragonFly from FreeBSD in recent history. A lot has changed in the intervening time, the infrastructure should be synchronized/updated to match the state-of-the-art in FreeBSD. At a minimum the drivers that currently work in DragonFly should be tested to ensure functionality and updates as well or improved.
-
-Meta information:
-
-* Prerequisites: C, x86 assembly, drivers
-* Difficulty: Moderate
-* Contact point: kernel@crater.dragonflybsd.org, #dragonfly irc channel
-
----
-
-##### Implement GEM for the DragonFly kernel
-
-The Graphics Execution Manager is a memory management system dedicated
-to Intel graphics chipsets. Along with KMS, it is a requirement of
-2010 and more recent Intel Xorg drivers.
-
-The dports third-party application collection already contains all the userland bits needed to use the new drivers, provided WITH_NEW_XORG and WITH_KMS options are used in make.conf
-
-Background GEM information:
-
-* http://en.wikipedia.org/wiki/Graphics_Execution_Manager
-* http://lwn.net/Articles/283798/
-* http://blog.ffwll.ch/2012/10/i915gem-crashcourse.html
-
-Some kernel work has already been done in this domain by FreeBSD and could probably be adapted:
-
-* https://wiki.freebsd.org/Intel_GPU
-
-Related work has also been done previously by David Shao during a 2010 GSoC project:
-
-* http://www.dragonflybsd.org/docs/developer/GEMdrmKMS/
-* https://github.com/davshao/dflygsocdrm
-
-The dflygsocdrm branch is kept up-to-date but sadly seems to only be working on i386 DragonFly systems, and with ~2010 era Intel chipsets.
-
-An experimental port of the FreeBSD i915/kms code is also available, albeit non-working due to the missing GEM support.
-
-Adding PAT (Page Attribute Table) support to the kernel seems to be a required first step:
-
-* http://lwn.net/Articles/278994/
-
-Meta information:
-
-* Prerequisites: C, x86 architecture and paging knowledge
-* Difficulty: Moderate to difficult
-* Contact point: kernel@crater.dragonflybsd.org, #dragonfly irc channel
-
----
-
##### Implement GEM for the DragonFly kernel
The Graphics Execution Manager is a memory management system dedicated
---
+
+##### HAMMER2 - Add block compression feature
+Add physical block compression to HAMMER2. In HAMMER2 the a block reference describes a logical block and points to a physical block. The physical block can be a different size than the logical block, thus it is possible to implement a compression algorithm to reduce physical space use on a block-by-block basis.
+
+* Add a hammer2 utility command and associated ioctl to set the compression mode on a directory, to be inherited by any new files or subdirectories created therein.
+
+* Implement one compression algorithm capable of doing block compression on a 64KB block of data. The compression succeeds if it is able to compress at least 50% (down to 32KB), in powers of 2 (16KB, 8KB, etc), and the block is written uncompressed otherwise.
+
+Meta information:
+
+* Prerequisites: C
+* Difficulty: Moderate
+* Contact point: kernel@lists.dragonflybsd.org, Matthew Dillon <dillon@backplane.com>
+
+---
+
+##### HAMMER2 - Add block encryption feature
+Add physical block encryption to HAMMER2.
+
+* 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).
+
+Meta information:
+
+* Prerequisites: C
+* Difficulty: Moderate
+* Contact point: kernel@lists.dragonflybsd.org, Matthew Dillon <dillon@backplane.com>
+
+---
+
+##### HAMMER2 - Add copies feature
+Add block redundancy to HAMMER2
+
+* 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.
+
+Meta information:
+
+* Prerequisites: C, heavy kernel knowledge
+* Difficulty: Hard
+* Contact point: kernel@lists.dragonflybsd.org, Matthew Dillon <dillon@backplane.com>
+
---
(please add)
projects / ikiwiki.git / blobdiff