gsoc2009/index.mdwn

   1 [[!meta title="Google Summer of Code 2009"]]
   2
   3 [[!toc  levels=3]]
   4
   5 Recently Google announced that there will be a **Google Summer of Code** this year.  After our successful participation last year, we should set up a list of possible projects and mentors this year as early as possible.  If you (as a student) want to come up with your own DragonFly-related project, please send an email to <kernel@lists.dragonflybsd.org> and describe your project.  More information about our student guidelines are available [[here|docs/developer/GoogleSoCStudent]].
   6
   7 Have a look at our [[pages|docs/developer/GoogleSoC2008/]] from 2008 to get an overview about last year's projects.
   8
   9 If you're a student, visit our [[SoC 2009 student page|gsoc2009student]].
  10
  11 [Google's SoC page](http://socghop.appspot.com/)
  12
  13 ## Possible projects
  14
  15 ### Binary updates for DragonFly
  16
  17 * **Mentor**: Matthias Schmidt <matthias@dragonflybsd.org>
  18 * **Difficulty**: Medium
  19 * **Required Skills**: Knowledge about Shell and C. Insights about our nrelease build process are helpful, but could be earned during the SoC.
  20 * **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.
  21
  22 ### A device file system (devfs)
  23
  24 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  25 * **Difficulty**: Medium
  26 * **Required Skills**: Knowledge about C, some understanding of kernel internals.
  27 * **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.
  28
  29 ### Support debugging of multi-threaded applications
  30
  31 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  32 * **Difficulty**: Medium
  33 * **Task**: DragonFly supports 1:1 userland threading using the libthread_xu library and lwps in the kernel.  Running multi-threaded applications works, but there is no debugging support yet.  In this project, you would have to devise and implement a kernel interface for debugging by implementing an extended version of ptrace.  In parallel with this, gdb will have to be extended to use this interface.  This project would be rounded off by adding support for crash dumps of multi-threaded applications.
  34
  35 ### Profile SMP kernel contention
  36
  37 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  38 * **Difficulty**: Medium
  39 * **Task**: Most of the DragonFly kernel still uses the MP lock to serialize kernel execution between different CPUs.  The goal of this task is to implement measurement methodologies and then in turn obtain numbers to quantify which parts of the kernel are responsible for bad MP performance.  The outcome of this project will influence which subsystems will have to be prioritized when parallelizing the kernel.
  40
  41 ### Enhance the HAMMER reblocker
  42
  43 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  44 * **Difficulty**: Medium
  45 * **Required Skills**: Knowledge about C, kernel internals and the HAMMER fs.
  46 * **Task**: HAMMER is the new DragonFly 64-bit file system, which provides fine-grained snapshots and off-/online mirroring.  One central property of HAMMER is that the file system itself will never delete data and recycle consumed storage.  This task is performed by a userland tool, called the reblocker, which is similar to a log cleaning tool of log structured file systems.  The goal of this project is to enhance the reblocker to optimize the data layout on disk, so that access times will be reduced.
  47
  48 ### Add redundant data storage to the HAMMER file system
  49
  50 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  51 * **Difficulty**: Quite demanding
  52 * **Required Skills**: Knowledge about C, kernel internals and the HAMMER fs.
  53 * **Task**: HAMMER is the new DragonFly 64-bit file system, which provides fine-grained snapshots and off-/online mirroring.  It would be desirable to support various redundant storage models (like RAID-1, RAID-5) within the file system, so that parts of the file system can be subject to one redundancy scheme, while other parts are subject to another, e.g. /home could be mirrored, but /tmp not (HAMMER uses something remotely similar to RAID-0 (using all disks) currently).  The advantage of implementing redundancy in the file system is that storage can instantly be grown by adding or replacing HDDs, something traditional block-level RAID systems can not achieve.  Furthermore, the userland reblocker (encapsulating a big part of the complexity) can be used to gradually improve the data layout of redundant data.
  54
  55 ### merge tool for configuration files (/etc)
  56
  57 * **Mentor**: Simon Schubert <corecode@dragonflybsd.org>
  58 * **Difficulty**: Easy
  59 * **Required Skills**: Knowledge about Shell, system upgrading, administrative tasks and git.
  60 * **Task**: System configuration is usually done by the administrator by manually editing (text) files in the /etc directory.  However new software versions (of the software included in the operating system) or changes in policy sometimes require modifications to the same configuration files.  Thus, there are two possible sources for changes in configuration files:  (1) the administrator and (2) the operating system distribution.  Most of the time, not both types of changes apply to a file, but only one, but sometimes both changes happen to the same file.  The purpose of a merge tool is to help the administrator to preserve her own changes (1) to the configuration files while applying the upstream changes (2).  A tool which helped in the past was the mergemaster(1).  However mergemaster is relying CVS $Tags$, which are not available anymore since DragonFly's switch to git.  A new merge tool would support the administrator in applying upstream changes without unnecessarily prompting the administrator for "obvious" operations.  It is desirable that the merge tool would make use of git(1), which will be installed anyways most of the time.
  61
  62 ### C99 and POSIX conformance audit
  63
  64 * **Mentor**: Hasso Tepper <hasso@estpak.ee>
  65 * **Difficulty**: Easy
  66 * **Required Skills**: Some knowledge about the used programming languages, POSIX standards.
  67 * **Task**: Audit DragonFly system with focus on C99 and POSIX (1003.1-2001) standards and try to make system conform to these standards as close as possible. Document the conformance bit by bit.
  68
  69 ### Quotas on Hammer
  70
  71 * **Mentor**: (none yet)
  72 * **Difficulty**: Medium
  73 * **Task**: Hammer filesystems can be segregated into pseudo-filesystems (PFS) but each PFS has a maximum size restricted only by the available space on the Hammer partition.  Quotas need to be implemented to keep this from happening.
  74
  75 ### Port valgrind
  76
  77
  78 * **Mentor**: (none yet)
  79 * **Difficulty**: Medium
  80 * **Task**: Valgrind is a very useful debugging tool, but it would take some effort to port it to DragonFly. Do the port and, if time permits, modify it so that we can use it with a vkernel process.
  81
  82 ## Projectless Mentors
  83
  84 * **Mentor**: Joe Talbott <josepht@dragonflybsd.org>
  85 * **Difficulty**: Medium
  86 * **Areas of Interest**: vkernel, cpu-scheduling, performance analysis
  87
  88 * **Mentor**: Samuel J. Greear <sjg@evilcode.net>
  89 * **Difficulty**: Medium
  90 * **Areas of Interest**: any
  91
  92 ## Potential Students
  93
  94 Keep in mind that no project is guaranteed to any student; acceptance is dependent on Google's qualification and a successful project proposal.  So if any topic interests you, please plan for it.
  95
  96 * **Student**: Stathis Kamperis <ekamperi@gmail.com> (Beket @ #dragonflybsd)
  97 * **Task of interest**: C99 and POSIX conformance audit
  98 * **Student**: Alex Hornung <ahornung@gmail.com> (alexh @ #dragonflybsd)
  99 * **Task of interest**: devfs
 100 * **Student**: Robert Luciani <rluciani@gmail.com> (r3tex @ #dragonflybsd)
 101 * **Task of interest**: Kernel SMP contention profiling