7 files changed, 318 insertions, 3 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 0e08532c..6475b9a5 100644
--- a/community/gsoc/project_ideas.mdwn
+++ b/community/gsoc/project_ideas.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2012, 2013, 2014, 2015,
-2016, 2017 Free Software Foundation, Inc."]]
+2016, 2017, 2018 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -105,7 +105,6 @@ project_ideas:
   community/gsoc/project_ideas/gdb
   community/gsoc/project_ideas/tcp_ip_stack
   community/gsoc/project_ideas/nfs
-  community/gsoc/project_ideas/sound
   community/gsoc/project_ideas/disk_io_performance
   community/gsoc/project_ideas/gnumach_cleanup
   community/gsoc/project_ideas/xmlfs
@@ -122,7 +121,6 @@ project_ideas:
   community/gsoc/project_ideas/testing_framework
   community/gsoc/project_ideas/libcap
   community/gsoc/project_ideas/valgrind
-  community/gsoc/project_ideas/dtrace
   community/gsoc/project_ideas/libdiskfs_locking"
 
 """]]
diff --git a/community/gsoc/project_ideas/dtrace.mdwn b/community/gsoc/project_ideas/dtrace.mdwn
new file mode 100644
index 00000000..f7aeb6e8
--- /dev/null
+++ b/community/gsoc/project_ideas/dtrace.mdwn
@@ -0,0 +1,67 @@
+[[!meta copyright="Copyright © 2008, 2009, 2011, 2018 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="Kernel Instrumentation"]]
+
+[[!tag open_issue_gnumach]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project."""]]
+
+
+One of the main problems of the current Hurd implementation is very poor
+[[open_issues/performance]]. While we have a bunch of ideas what could cause the performance
+problems, these are mostly just guesses. Better understanding what really
+causes bad performance is necessary to improve the situation.
+
+For that, we need tools for performance measurements. While all kinds of more
+or less specific [[open_issues/profiling]] tools could be conceived, the most promising and
+generic approach seems to be a framework for logging certain events in the
+running system (both in the microkernel and in the Hurd servers). This would
+allow checking how much time is spent in certain modules, how often certain
+situations occur, how things interact, etc. It could also prove helpful in
+debugging some issues that are otherwise hard to find because of complex
+interactions.
+
+The most popular kernel instrumentation framework is Sun's dtrace,
+originally written for Solaris,
+but also adopted by some other systems.
+However, the GPL-incompatible license means it can't be used in Linux,
+and thus Linux developers created their own frameworks instead:
+first [[SystemTap]], and now [[LTTng]].
+
+In 2008, Andrei Barbu did initial work on kernel probes for the Hurd.
+However, not all of his patches got merged,
+because some turned out not to be fully functional.
+Also, he didn't get around to work on userspace probes,
+nor on a nice frontend for writing test scripts employing the probes.
+
+The goal of this project is to make the instrumentation framework
+more usable and complete,
+and to better integrate it in the Hurd.
+For that, the student will have to work
+on some real profiling and/or debugging tasks,
+and fix any shortcomings he encounters in the framework.
+
+This is a pretty involved task.
+Previous experience with low-level programming is a must;
+and it also requires a good grasp on interactions in complex systems.
+
+To work on this project,
+the student will have to get familiar with GNU Mach.
+(The microkernel employed by the Hurd.)
+Some understanding of other aspects of the Hurd will also be required,
+depending on the exact nature of the profiling/debugging performed.
+
+Exercise: Use the existing probes to perform some simple measurement.
diff --git a/community/gsoc/project_ideas/file_locking.mdwn b/community/gsoc/project_ideas/file_locking.mdwn
new file mode 100644
index 00000000..a368a7a8
--- /dev/null
+++ b/community/gsoc/project_ideas/file_locking.mdwn
@@ -0,0 +1,47 @@
+[[!meta copyright="Copyright © 2008, 2009, 2012, 2014, 2018 Free Software
+Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="Fix and Complete File Locking Support"]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project."""]]
+
+
+Over the years, [[UNIX]] has acquired a host of different file locking mechanisms.
+Some of them work on the Hurd, while others are buggy or only partially
+implemented. This breaks many applications.
+
+The goal is to make all file locking mechanisms work properly. This requires
+finding all existing shortcomings (through systematic testing and/or checking
+for known issues in the bug tracker and mailing list archives), and fixing
+them. The biggest missing feature is record locking, i.e. the lockf variant,
+which needs a complete implementation.
+
+This task will require digging into parts of the code to understand how file
+locking works on the Hurd. Only general programming skills are required.
+
+A preliminary patch is [[!GNU_Savannah_patch 332 desc="available"]].
+
+Exercise: Find one of the existing issues, either by looking at the task/bug
+filed on [[open_issues/file_locking]], on
+trackers on savannah, or by trying things out yourself; and take a go at it.
+Note though that most of these issues are probably not trivial -- it's quite
+likely that you won't be able to actually fix any of them in the time available
+during the application process. However, you might be able to spot something
+else that could be improved while looking into this.
+
+If after trying for a while you haven't found anything easy enough to improve
+in the locking-related code, talk to us about some alternative exercise task.
+Perhaps you actually find something you could do while looking through the bug
+tracker or trying stuff yourself in search of locking issues :-)
diff --git a/community/gsoc/project_ideas/physical_memory_management.mdwn b/community/gsoc/project_ideas/physical_memory_management.mdwn
new file mode 100644
index 00000000..af360507
--- /dev/null
+++ b/community/gsoc/project_ideas/physical_memory_management.mdwn
@@ -0,0 +1,58 @@
+[[!meta copyright="Copyright © 2015, 2016, 2018 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Physical memory management"]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project; it was basically
+done by Richard."""]]
+
+
+GNU Mach is currently suffering from severe limitations caused by the way
+it manages physical memory. For example, since it requires pages to be mapped
+in kernel space in order to be used, the maximum amount of usable physical
+memory is currently around 800MB (or 1.8GB if a 2/2 split is set). And
+because the page allocator is unable to easily return blocks of contiguous
+pages, the kernel has to use virtual memory to provide contiguity.
+But the kernel virtual space is separate from the direct mapping of
+physical memory, so the larger it is, the less physical pages available.
+The size of the kernel space is currently around 200MB, with around 100MB
+for kernel objects. This small size prevents the system from achieving
+scalability, since a panic occurs when the kernel is unable to allocate
+a kernel object such as a port. In addition, the kernel uses mainly tables
+to store IPC rights. When a table is full, it is enlarged through a kernel
+specific version of realloc(). When a file system starts managing many
+files (e.g. because some of their content is cached in physical memory),
+these tables can get big enough to make realloc() fail because of
+fragmentation.
+
+The goal of this project is to make as much physical memory available as
+possible for both the kernel and applications, by rewriting the page
+allocator into a buddy allocator to support contiguous block allocations,
+using it directly instead of virtual memory as the backend of the slab
+allocator for kernel objects, and, if time allows it, transform IPC right
+tables (e.g. into radix trees) and get rid of realloc().
+
+This project requires a good understanding of virtual memory (both physical
+mappings at the MMU level and virtual mappings at the VM level), and strong
+skills in C programming. Note that some work has already been done in the
+X15 project about this, and can be reused as a reference.
+
+Useful links :
+
+ * <https://www.sceen.net/mapping-physical-memory-directly/>
+
+ * <http://git.sceen.net/rbraun/x15.git/>
+
+ * <https://git.sceen.net/rbraun/librbraun.git/plain/rdxtree.h>
diff --git a/community/gsoc/project_ideas/sound.mdwn b/community/gsoc/project_ideas/sound.mdwn
new file mode 100644
index 00000000..1a33ae2c
--- /dev/null
+++ b/community/gsoc/project_ideas/sound.mdwn
@@ -0,0 +1,48 @@
+[[!meta copyright="Copyright © 2008, 2009, 2018 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Sound Support"]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project."""]]
+
+
+The Hurd presently has no sound support.  Fixing this, [[!GNU_Savannah_task
+5485]], requires two steps: the first is to port some other kernel's drivers to
+[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound
+hardware.  The second is to implement a userspace server ([[hurd/translator]]),
+that implements an interface on top of the kernel device that can be used by
+applications -- probably OSS or maybe ALSA.
+
+Completing this task requires porting at least one driver (e.g. from Linux) for
+a popular piece of sound hardware, and the basic userspace server. For the
+driver part, previous experience with programming kernel drivers is strongly
+advisable. The userspace part requires some knowledge about programming Hurd
+translators, but shouldn't be too hard.
+
+Once the basic support is working, it's up to the student to use the remaining
+time for porting more drivers, or implementing a more sophisticated userspace
+infrastructure. The latter requires good understanding of the Hurd philosophy,
+to come up with an appropriate design.
+
+Another option would be to evaluate whether a driver that is completely running
+in user-space is feasible.  <!-- TODO.  Elaborate.  -->
+
+Exercise: This project requires kernel (driver framework) hacking as well as
+some Hurd server hacking; so the exercise should involve either of these, or
+even both. You could for example port some newer driver to run in the existing
+framework (see the [[device_driver|driver_glue_code]] project description), or
+try to make some fix(es) to the [unfinished random device
+implementation](http://savannah.gnu.org/patch/?6088) created by Michael
+Casadevall.
diff --git a/community/gsoc/project_ideas/sound/discussion.mdwn b/community/gsoc/project_ideas/sound/discussion.mdwn
new file mode 100644
index 00000000..4a95eb62
--- /dev/null
+++ b/community/gsoc/project_ideas/sound/discussion.mdwn
@@ -0,0 +1,47 @@
+[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!taglink open_issue_documentation]]: update [[sound]] page.
+
+
+# IRC, freenode, #hurd, 2013-09-01
+
+    <rekado> I'm new to the hurd but I'd love to learn enough to work on sound
+      support.
+    <rekado>
+      http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/
+      says drivers should be ported to GNU Mach as a first step.
+    <rekado> Is this information still current or should the existing Linux
+      driver be wrapped with DDE instead?
+    <auronandace> if i recall correctly dde is currently only being used for
+      network drivers. i'm not sure how much work would be involved for sound
+      or usb
+
+
+## IRC, freenode, #hurd, 2013-09-02
+
+    <rekado> The sound support proposal
+      (http://darnassus.sceen.net/~hurd-web/community/gsoc/project_ideas/sound/)
+      recommends porting some other kernel's sound driver to GNU Mach.  Is this
+      still current or should DDE be used instead?
+    <pinotree> rekado: dde or anything userspace-based is generally preferred
+    <braunr> rekado: both are about porting some other kernel's sound driver
+    <braunr> dde is preferred yes
+    <rekado> This email says that sound drivers are already partly working with
+      DDE: http://os.inf.tu-dresden.de/pipermail/l4-hackers/2009/004291.html
+    <rekado> So, should I just try to get some ALSA kernel parts to compile
+      with DDE?
+    <pinotree> well, what is missing is also the dde←→hurd glue
+    <braunr> rekado: there is also a problem with pci arbitration
+    <rekado> pinotree: I assumed DDEKit works with the hurd and we could use
+      any DDE/<other kernel> glue code with it
+    * rekado looks up pci arbitration
+    <pinotree> only for networking atm
+    <rekado> ah, I see.
diff --git a/community/gsoc/project_ideas/xattr.mdwn b/community/gsoc/project_ideas/xattr.mdwn
new file mode 100644
index 00000000..f35498fe
--- /dev/null
+++ b/community/gsoc/project_ideas/xattr.mdwn
@@ -0,0 +1,50 @@
+[[!meta copyright="Copyright © 2009, 2016, 2018 Free Software Foundation,
+Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled
+[[GNU Free Documentation License|/fdl]]."]]"""]]
+
+[[!meta title="Implement xattr Support"]]
+
+[[!template id=highlight text="""/!\ Obsolete /!\
+
+---
+
+This is no longer valid as a Google Summer of Code project; it's done."""]]
+
+
+Extended attributes (xattr) are a standardized, generic method for storing
+additional metadata along with a file (inode). Most modern UNIX filesystems
+support xattrs.
+
+In general, xattrs should be used sparingly, as they are less transparent than
+data stored as explicit file contents; however, there are some cases where they
+really make sense. The Hurd's variant of ext2 presently uses some additional
+fields in the inode to store Hurd-specific metadata: most notable passive
+translator settings. As these fields are Hurd-specific, they can't be accessed
+by the standard methods from Linux for example, so it's not possible to fully
+work with a Hurd filesystem on GNU/Linux (copy, backup etc.); and also, even
+when on Hurd, only tools that explicitly support the Hurd-specific information
+can handle them.
+
+Using extended attributes instead of custom fields for the Hurd-specific
+information would be very helpful.
+
+The most important goal of this project thus is to make the Hurd ext2fs server
+able to store and read the Hurd-specific information with extended attributes
+instead of the custom fields, so it become accessible from other systems. Being
+able to access the information through the standard xattr API instead of
+Hurd-specific calls is also desirable. (And in turn requires implementing the
+generic xattr API first, which can be useful for other purposes as well.)
+
+Completing this project will require digging into some parts of the Hurd, but
+it should be quite doable without previous Hurd experience. Some experience
+with xattrs might help a bit, but shouldn't be really necessary either.
+
+Some previous work on xattr support is [[available|open_issues/xattr]], and
+might serve as a starting point.