(no commit message)
authorcorecode <corecode@web>
Sat, 21 Feb 2009 21:12:35 +0000 (13:12 -0800)
committerCharlie <root@leaf.dragonflybsd.org>
Sat, 21 Feb 2009 21:12:35 +0000 (13:12 -0800)
gsoc2009/index.mdwn

index e47744f..c1f6d9d 100644 (file)
@@ -13,3 +13,9 @@ Have a look at our [[pages|docs/developer/GoogleSoC2008/]] from 2008 to get an o
 * **Mentor**: Matthias Schmidt <matthias@dragonflybsd.org>
 * **Difficulty**: Medium
 * **Task**: We have currently no way to update our system without compiling from sources.  While this is great for most desktops/workstations it is inappropriate for production systems or even servers. Recompiling a whole system or even only pieces from source requires a certain knowledge, consumes time and resources. A binary updater should solve this problem. It must be able to download either single security patches (deltas to existing release binaries) or to upgrade a whole system from one major release to another (e.g from 2.0 -> 2.2). This eases the work flow for either users and administrators. Other Operating Systems have solutions for this (e.g. the work of Collin Percival of FreeBSD and his freebsd-update and NetBSD has some kind of binary updater) but this solutions are not suitable for DragonFly. The students has to come up with a solution which fits the needs of DragonFly and uses our existing build infrastructure (the nrelease framework). Of course all offered binary patches need to be distributed in a safe manner to prevent misuse. The build infrastructure for the patches has to take several glitches into account, e.g. build timestamps etc.  The ultimate goal would be to have an (automatic) script providing updates on a server (for fixes and major updates) and a client which is able to download and install the updates (and of course make appropriate backups). Victor Balada Diaz serves as co-mentor here.
+
+### devfs
+
+* **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
+* **Difficulty**: Medium
+* **Task**: DragonFly currently uses standard device nodes in /dev, backed by either UFS or HAMMER.  Often problems crop up when device nodes are missing, or confusion arises if device nodes exist without the corresponding device in the kernel.  Also, the vnode interface for devices currently prevents the implementation of cloning devices, which can be useful for automatic sound vchannels, etc.  The new devfs needs to be developed from scratch and can not be ported from other operating systems.