5 files changed, 114 insertions, 10 deletions
diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn
index 714f37da..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, 2018 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
diff --git a/community/gsoc/project_ideas/driver_glue_code.mdwn b/community/gsoc/project_ideas/driver_glue_code.mdwn
index c1850d21..1771756e 100644
--- a/community/gsoc/project_ideas/driver_glue_code.mdwn
+++ b/community/gsoc/project_ideas/driver_glue_code.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 2016 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011, 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
@@ -27,7 +27,7 @@ This is [[!GNU_Savannah_task 5488]].
 [[open issues/user-space device drivers]].
 [[open issues/device drivers and io systems]].
 
-The most promising approach for getting newer drivers seems to be the Rump kernel:
+The most promising approach for getting newer drivers seems to be the [[Rump_Kernel]]:
 it already does the hard work of providing an environment
 where the foreign drivers can run,
 and offers the additional benefit of being externally maintained.
@@ -69,8 +69,3 @@ such as memory management for example.
 Possible mentors: Justus Winter (teythoon), Samuel Thibault (youpi)
 
 Exercise: Install and run the current rumpkernel library (librump0) and the corresponding mplayer, get it to run.
-
----
-
-
-# 2016-02-14, Justus Winter
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/tcp_ip_stack.mdwn b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
index 6410dee0..f86dcf72 100644
--- a/community/gsoc/project_ideas/tcp_ip_stack.mdwn
+++ b/community/gsoc/project_ideas/tcp_ip_stack.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2009, 2017 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
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.