Merge branch 'master' of flubber:~hurd-web/hurd-web

21 files changed, 303 insertions, 49 deletions

diff --git a/contributing.mdwn b/contributing.mdwn
index c006e554..1745b61a 100644
--- a/contributing.mdwn
+++ b/contributing.mdwn
@@ -16,7 +16,7 @@ Every single contribution is very much encouraged.
 
 There are various ways to contribute; read up on contributing to...
 
-[[!toc levels=3]]
+[[!toc levels=4]]
 
 If someone of you is lurking around here and would like to contribute, but
 feels she / he could do so better under formal mentoring: please
@@ -77,31 +77,47 @@ documents.
 <a name="porting"></a>
 ## Porting Packages
 
-Debian is currently the Hurd distribution of choice among Hurd users and
-developers.
+Please [[contact_us]] before spending a lot of time on the following porting
+tasks: some work may already have been done that you can base your work upon.
 
-Here is a
-[[list_of_Debian_packages_that_need_porting|hurd/running/debian/porting]].
+For guidelines, please have a look at the dedicated [[porting_page|hurd/porting]].
 
-You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what
-doesn't work or suit you and try to improve that.
 
-You can also have a look at the [List of failing packages](http://people.debian.org/~sthibault/failed_packages.txt).
+### Debian GNU/Hurd
 
-For guidelines, please have a look at the dedicated [[porting_page|hurd/porting]].
+[[!template id=note text="""#### Debian Wheezy Release
 
+There is a goal of getting Debian GNU/Hurd into shape for a proper release with
+Debian Wheezy (expected towards the end of 2012 or beginning of 2013).
 
-## Open Issues
+The *to do* list is on <http://wiki.debian.org/Debian_GNU/Hurd>."""]]
 
-There is a list of [[open_issues]].  This list includes everything from bug
-reports to open-ended research questions.
+The following missing packages/missing functionality block a lot of other
+packages, and are thus good candidates for porting, in order to increase
+archive coverage:
 
+* umount functionality in busybox
+* gtest
+* hdf5
+* hyperestraier
+* sane*
+* ghc (ghc6 and ghc7)
+* [[open_issues/gnat]]
+* ruby1.9.1
 
-## Debian Wheezy release
+Here is a [[list of packages that need porting|hurd/running/debian/porting]].
 
-We target the Debian Wheezy release!
+You can also just [[install_Debian_GNU/Hurd|hurd/running/debian]] and find what
+doesn't work or suit you and try to improve that.
+
+Or, you can pick one from the [list of failing
+packages](http://people.debian.org/~sthibault/failed_packages.txt).
 
-The *to do* list is on <http://wiki.debian.org/Debian_GNU/Hurd>.
+
+## Open Issues
+
+There is a list of [[open_issues]].  This list includes everything from bug
+reports to open-ended research questions.
 
 
 <a name="insta-dev-env"></a>
diff --git a/contributing/discussion.mdwn b/contributing/discussion.mdwn
new file mode 100644
index 00000000..5a6bfd7c
--- /dev/null
+++ b/contributing/discussion.mdwn
@@ -0,0 +1,21 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# One-stop Development Environment
+
+Invent something.
+
+
+# Mailing Lists
+
+Add link to [[mailing_lists]] to page, and suggest following these.
diff --git a/contributing/web_pages/news/moth_next.mdwn b/contributing/web_pages/news/moth_next.mdwn
index dec41583..e8a0428a 100644
--- a/contributing/web_pages/news/moth_next.mdwn
+++ b/contributing/web_pages/news/moth_next.mdwn
@@ -67,4 +67,9 @@ And …
 
   * <http://blog.schmehl.info/Debian/hurd-not-default>
 
+  * LWN
+
+  * Bits from the Debian GNU/Hurd porters,
+    id:"20110721172827.GF4057@const.famille.thibault.fr"
+
 """]]
diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn
index 4586a8e6..e5c8c160 100644
--- a/hurd/documentation/translator_primer.mdwn
+++ b/hurd/documentation/translator_primer.mdwn
@@ -41,7 +41,11 @@ Then you setup the translator /hurd/hello in the file/node hello.
 
 After that you check the contents of the file, and the translator returns "Hello World!". 
 
-To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. 
+To finish it,
+you remove the translator from the file "hello"
+(and tell any active running instances to go away)
+via "settrans -g hello".
+Having done that, verify that now the file is empty again.
 
 ### Transparent FTP
 
diff --git a/hurd/faq/off.mdwn b/hurd/faq/off.mdwn
index 363436b0..64009101 100644
--- a/hurd/faq/off.mdwn
+++ b/hurd/faq/off.mdwn
@@ -19,3 +19,7 @@ will not work. Simply use the equivalent shortcut
     $ halt
 
 which is provided natively on GNU/Hurd, instead of from SYSV runlevels.
+
+Note that due to a bug,
+we [[recommend you run syncfs|open_issues/sync_but_still_unclean_filesystem]]
+prior to issuing the `halt` command.
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index b66af7de..64e3776e 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -166,3 +166,21 @@ IRC, freenode, #hurd, 2011-03-28
       mentoring the previous procfs implementation
     <antrik> (though I never got around to look at his buggy code...)
     <jkoenig> ok
+
+IRC, freenode, #hurd, 2011-07-22
+
+    <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux?
+    <jkoenig> pinotree, it reveals information which, while not that sensitive,
+      would not be available to users through the normal proc interface.
+    <jkoenig> (it's available through the ps command which is setuid root)
+    <jkoenig> we discussed at some point making it 644, IIRC.
+    <pinotree> hm, then why is it not a problem on eg linux?
+    <jkoenig> (btw you can change it with the -s option.)
+    <jkoenig> pinotree, it's not a problem because the information is not that
+      sensitive, but when rewriting procfs I preferred to play it self and
+      consider it's not procfs' job to decide what is sensitive or not.
+    <jkoenig> IIRC it's not sensitive but you need the task port to query it.
+    <jkoenig> like, thread times or something.
+    <pinotree> status is 644 though
+    <jkoenig> but status contains information which anyone can ask to the proc
+      server anyway, I think.
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 2152c079..6c984784 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 # CPU Architecture
 
@@ -68,10 +68,11 @@ All common IDE drives should work.  Some drive geometries do not work,
 e.g. drives with hundreds of GiB of storage space, see [[!GNU_Savannah_bug
 26425]].
 
-[[!toggle id="SATA" text="SATA drives may work in compatibility mode."]]
-<!-- Sure?  --[[tschwinge]] -->
 
-[[!toggleable id="SATA" text="""
+## SATA
+
+SATA drives may work in compatibility mode.
+
 This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach
 couldn't connect to the hard disk, e.g., in a SATA system without IDE
 compatibility mode:
@@ -81,7 +82,7 @@ compatibility mode:
 
 There *may* be an option in the system's BIOS setup to configure enabling such
 a compatibility mode.
-"""]]
+
 
 # Device Drivers
 
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
index 69ca3190..2b65956a 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn
@@ -1,4 +1,33 @@
+[[!meta copyright="Copyright © 2007, 2008, 2011 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]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
 Further information may still be found on
 <http://www.nongnu.org/thug/gnumach_hardware.html>
 and could perhaps be incorporated into that page.
 --[[tschwinge]]
+
+
+# SATA
+
+IRC, freenode, +hurd, 2011-07-24
+
+    <braunr> youpi: concerning the ide compatibility problem, it seems some
+      bioses provide several modes
+    <braunr> youpi: "legacy ide" and "native ide"
+    <braunr> i don't know what native ide really means, but when debugging ide
+      probing in gnumach, it just looks like there is nothing to detect
+    <braunr> and even in this mode, linux uses the ahci driver
+    <youpi> apparently native means it still uses the IDE protocol, but
+      possibly with other IRQs
+    <youpi> i.e. you need a PCI driver to handle that
+    <braunr> ok
diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn
index ba2e22c2..7f02628d 100644
--- a/microkernel/mach/port.mdwn
+++ b/microkernel/mach/port.mdwn
@@ -49,7 +49,7 @@ send-once right.  These messages are (probably) queued and when the server task
 tries to receive messages by having a [[thread]] use its port receive right, it
 gets the message(s).  This is called [[IPC]].
 
-Port rights themselvse can be [[delegate]]d in a [[message]], too.  When the
+Port rights themselves can be [[delegate]]d in a [[message]], too.  When the
 receiver dequeues the message, the right is made available to it.
 
 The delivery of [[message]]s is reliable and strictly ordered.  When a
diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn
index be9cef50..cbf039b0 100644
--- a/news/2011-q2-ps.mdwn
+++ b/news/2011-q2-ps.mdwn
@@ -33,12 +33,12 @@ In the following, we try to clear the situation up a bit.
     want to help, please see our [[contributing]] page and the *to do* list
     maintained on <http://wiki.debian.org/Debian_GNU/Hurd>.
 
-  * *GNU Hurd developers want the Linux kernel to die*.  {X} **Wrong**.  All of
-    us are happy users of the Linux kernel, every day, and GNU/Linux is the
-    free operating system of choice, which we're using ourselves (unless
-    sitting in front of a GNU/Hurd system).  We don’t work on the GNU Hurd due
-    to any hatred against the Linux kernel or even Linus; we work on it because
-    of the [[additional capabilities and clean design|advantages]] that it
+  * *GNU Hurd developers want the Linux kernel to die*.  {X}
+    **Wrong**.  All of us are happy users of the Linux kernel, every
+    day, and GNU/Linux is the free operating system of choice, which
+    we're using ourselves (unless sitting in front of a GNU/Hurd
+    system). We work on the Hurd instead of Linux because of the
+    [[additional capabilities and clean design|advantages]] it
     provides.
 
   * *Java support for GNU/Hurd is in the works*.  (./) **True**.  Jérémie
diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index 1c3bc022..b3f58832 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -30,8 +30,8 @@ though, as explained below.
 
 # Configuration
 
-Last reviewed up to the [[Git mirror's 57a1a9e822a763aeeb3ea66fd493aa58888c76c4
-(2011-07-03) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's 63dd9daf3e4b1fdad043bda3377bc1a078f9bfe1
+(2011-07-22) sources|source_repositories/binutils]].
 
   * Globally
 
diff --git a/open_issues/gcc.mdwn b/open_issues/gcc.mdwn
index f0f2af51..37864524 100644
--- a/open_issues/gcc.mdwn
+++ b/open_issues/gcc.mdwn
@@ -67,8 +67,8 @@ testsuite.
 
 # Configuration
 
-Last reviewed up to the [[Git mirror's 7c9f953a01d23c6b6885dc908d5b1dba8009efd4
-(2011-07-18) sources|source_repositories/gcc]].
+Last reviewed up to the [[Git mirror's 6678cb4ef6c7d8d9232249b5d722a0d6dfd328b5
+(2011-07-22) sources|source_repositories/gcc]].
 
 <http://gcc.gnu.org/install/configure.html> has documentation for the
 `configure` switches.
@@ -170,14 +170,11 @@ Last reviewed up to the [[Git mirror's 7c9f953a01d23c6b6885dc908d5b1dba8009efd4
 
     `check_effective_target_pie` should include `*-*-gnu*`, too.
 
-  * [high] 9b0fef97f18ed5c9f2f9a361262fbb450f2b0b53
-
-    Very likely needed for us, too.  Patch on gcc-patches and in
-    *config/extra_parts* branch.
-
 
 # Build
 
+  * Waiting: ef3c41c78d877ac478ddaac3942243f9bd0844f3 switches to g++.
+
 Here's a log of a GCC build run; this is from our [[Git repository's
 09ba3e78c07654e08c8bef82761dbbb26d3c00c9 (2011-07-18)
 sources|source_repositories/gcc]], run on kepler.SCHWINGE and coulomb.SCHWINGE.
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index f15c4d25..448aafcc 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -894,3 +894,32 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> ok
     <braunr> it's tricky
     <braunr> mcsim: try to find where the first use of the allocator is made
+
+
+# IRC, freenode, #hurd, 2011-07-22
+
+    <mcsim> braunr, hello. Kernel with your allocator already compiles and
+      runs. There still some problems, but, certainly, I'm on the final stage
+      already. I hope I'll finish in a few days.
+    <tschwinge> mcsim: Oh, cool!  Have you done some measurements already?
+    <mcsim> Not yet
+    <tschwinge> OK.
+    <tschwinge> But if it able to run a GNU/Hurd system, then that already is
+      something, a big milestone!
+    <braunr> nice
+    <braunr> although you'll probably need to tweak the garbage collecting
+      process
+    <mcsim> tschwinge: thanks
+    <mcsim> braunr: As back-end for allocating memory I use
+      kmem_alloc_wired. But in zalloc was an opportunity to use as back-end
+      kmem_alloc_pageable. Although there was no any zone that used
+      kmem_alloc_pageable. Do I need to implement this functionality?
+    <braunr> mcsim: do *not* use kmem_alloc_pageable()
+    <mcsim> braunr: Ok. This is even better)
+    <braunr> mcsim: in x15, i've taken this even further: there is *no* kernel
+      vm object, which means all kernel memory is wired and unmanaged
+    <braunr> making it fast and safe
+    <braunr> pageable kernel memory was useful back when RAM was really scarce
+    <braunr> 20 years ago
+    <braunr> but it's a source of deadlock
+    <mcsim> Indeed. I'll won't use kmem_alloc_pageable.
diff --git a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
index b2b20c5b..90137766 100644
--- a/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
+++ b/open_issues/gnumach_vm_map_entry_forward_merging.mdwn
@@ -171,6 +171,22 @@ License|/fdl]]."]]"""]]
       entries)
 
 
+# IRC, freenode, #hurd, 2011-07-21
+
+    <braunr> tschwinge: you may remove the forward map entry merging issue :/
+    <pinotree> what did you discover?
+    <braunr> tschwinge: it's actually much more complicated than i thought, and
+      needs major changes in the vm, and about the way anonymous memory is
+      handled
+    <braunr> from what i could see, part of the problem still exists in freebsd
+    <braunr> for the same reasons (shadow objects being one of them)
+
+
+# GCC build time using bash vs. dash
+
+<http://gcc.gnu.org/ml/gcc/2011-07/msg00444.html>
+
+
 # Procedure
 
   * Analyze.
@@ -181,8 +197,4 @@ License|/fdl]]."]]"""]]
 
   * Measure again.
 
-  * Have [[tschwinge]] measure with gcc build (currently needs 11 h).
-    [[tschwinge]] will in the mean time figure out the difference between using
-    bash and dash.
-
   * Have Samuel measure on the buildd.
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
new file mode 100644
index 00000000..f60c81a4
--- /dev/null
+++ b/open_issues/libpthread_dlopen.mdwn
@@ -0,0 +1,36 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!tag open_issue_libpthread]]
+
+IRC, OFTC, #debian-hurd, 2011-07-21.
+
+    <youpi> there's one known issue with pthreads
+    <youpi> you can't dlopen() it
+    <youpi> which also means you can't dlopen() a module which depends on it if
+      the main application hasn't used -lpthread already
+    <youpi> (so as to get libpthread initialized early, not at the dlopen()
+      call)
+    <lucas> I get this while building simgrid:
+    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
+      /usr/bin/cmake -E create_symlink
+      /home/lucas/simgrid-3.6.1/obj-i486-gnu/lib/libsimgrid.so
+      /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console/simgrid.so
+    <lucas> cd /home/lucas/simgrid-3.6.1/obj-i486-gnu/examples/gras/console &&
+      lua /home/lucas/simgrid-3.6.1/examples/gras/console/ping_generator.lua
+    <lucas> lua:
+      /home/buildd/build/chroot-sid/home/buildd/byhand/hurd/./libpthread/sysdeps/generic/pt-mutex-timedlock.c:68:
+      __pthread_mutex_timedlock_internal: Assertion `__pthread_threads' failed.
+    <lucas> Aborted (core dumped)
+    <youpi> that's it, yes
+    <youpi> (or at least it has the same symptoms)
+    <lucas> it would need fixing in lua, not in SG, then, right?
+    <youpi> yes
+    <lucas> ok, thanks
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index 18fc257e..4309494d 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -31,6 +31,10 @@ instead they should be scaled according to the backends' characteristics.
 
 The [[hurd/Critique]] should have some more on this.
 
+[*Event-based Concurrency
+Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.pdf),
+Tom Van Cutsem, 2009.
+
 
 # Alternative approaches:
 
diff --git a/open_issues/performance/io_system/clustered_page_faults.mdwn b/open_issues/performance/io_system/clustered_page_faults.mdwn
index 37433e06..9e20f8e1 100644
--- a/open_issues/performance/io_system/clustered_page_faults.mdwn
+++ b/open_issues/performance/io_system/clustered_page_faults.mdwn
@@ -12,7 +12,10 @@ License|/fdl]]."]]"""]]
 
 [[community/gsoc/project_ideas/disk_io_performance]].
 
-IRC, freenode, #hurd, 2011-02-16
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-02-16
 
     <braunr> exceptfor the kernel, everything in an address space is
       represented with a VM object
@@ -88,9 +91,8 @@ IRC, freenode, #hurd, 2011-02-16
     <braunr> recommend*
     <etenil> ok
 
----
 
-IRC, freenode, #hurd, 2011-02-16
+# IRC, freenode, #hurd, 2011-02-16
 
     <antrik> etenil: OSF Mach does have clustered paging BTW; so that's one
       place to start looking...
@@ -103,3 +105,35 @@ IRC, freenode, #hurd, 2011-02-16
       can serve as a starting point
 
 <http://lists.gnu.org/archive/html/bug-hurd/2010-06/msg00023.html>
+
+
+# IRC, freenode, #hurd, 2011-07-22
+
+    <braunr> but concerning clustered pagins/outs, i'm not sure it's a mach
+      interface limitation
+    <braunr> the external memory pager interface does allow multiple pages to
+      be transfered
+    <braunr> isn't it an internal Mach VM problem ?
+    <braunr> isn't it simply the page fault handler ?
+    <antrik> braunr: are you sure? I was under the impression that changing the
+      pager interface was among the requirements...
+    <antrik> hm... I wonder whether for pageins, it could actually be handled
+      in the pages instead of Mach... though this wouldn't work for pageouts,
+      so probably not very helpful
+    <antrik> err... in the pagers
+    <braunr> antrik: i'm almost sure
+    <braunr> but i've be proven wrong many times, so ..
+    <braunr> there are two main facts that lead me to think this
+    <braunr> 1/
+      http://www.gnu.org/software/hurd/gnumach-doc/Memory-Objects-and-Data.html#Memory-Objects-and-Data
+      says lengths are provided and doesn't mention the limitation
+    <braunr> 2/ when reading about UVM, one of the major improvements (between
+      10 and 30% of global performance depending on the benchmarks) was
+      implementing the madvise semantics
+    <braunr> and this didn't involve a new pager interface, but rather a new
+      page fault handler
+    <antrik> braunr: hm... the interface indeed looks like it can handle
+      multiple pages in both directions... perhaps it was at the Hurd level
+      where the pager interface needs to be modified, not the Mach one?...
+    <braunr> antrik: would be nice wouldn't it ? :)
+    <braunr> antrik: more probably the page fault handler
diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn
index 95b9e545..39478f20 100644
--- a/open_issues/placement_of_virtual_memory_regions.mdwn
+++ b/open_issues/placement_of_virtual_memory_regions.mdwn
@@ -10,7 +10,7 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-07-13
+# IRC, freenode, #hurd, 2011-07-13
 
     <braunr> does anyone know if posix (or mach) has requirements or a policy
       about the placement of allocations of virtual space ?
@@ -87,3 +87,17 @@ IRC, freenode, #hurd, 2011-07-13
     <braunr> jkoenig: i really want to miss as little as possible on the vm
       part, so having detailed information about what actually happens on
       running hurd systems is something i need
+
+
+# IRC, freenode, #hurd, 2011-07-24
+
+    <braunr> oh btw, i noticed there are many mappings below the program text
+    <braunr> most notably, the stack
+    <braunr> except for special applications like wine, could this break
+      anything ?
+    <braunr> i also wonder how libraries are mapped, because there is nothing
+      to perform top-down allocations
+    <braunr> which means if the region below the program text is exhausted,
+      libraries could be mapped right after the heap
+    <youpi> it shouldn't break anything except things like wine & libgc, yes
+    <braunr> which could make malloc() fail :/
diff --git a/open_issues/rm_fr.mdwn b/open_issues/rm_fr.mdwn
index 89a803ab..aab52d97 100644
--- a/open_issues/rm_fr.mdwn
+++ b/open_issues/rm_fr.mdwn
@@ -25,3 +25,15 @@ really waits for all I/Os, which basically means strictly serializing
 file removals: remove one file, wait for the disk to have done it
 (~10ms), remove the next one, etc.  I guess this is for safety reasons
 against crashes, but isn't the sync option there for such kind of
+
+
+# IRC, freenode, #hurd, 2011-07-23
+
+    <antrik> youpi: hm... async deletion does have one downside: I just removed
+      something to make space, and retried the other command immediately
+      afterwards, and it still said "no space left on device"... a few seconds
+      later (after the next regular sync I suppose?) it worked
+    <youpi> well, that's sorta expected, yes
+    <youpi> we get the same on Linux
+    <youpi> Mmm, on second thought, I'm not sure how that can happen
+    <youpi> the asynchronous thing is for disk writes, not cache writes
diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn
index edc92796..cee7a2bc 100644
--- a/open_issues/translators_set_up_by_untrusted_users.mdwn
+++ b/open_issues/translators_set_up_by_untrusted_users.mdwn
@@ -272,3 +272,12 @@ License|/fdl]]."]]"""]]
       to solve security issues at all
     <antrik> and as braunr already pointed out, this wouldn't help with DoS
       problems
+
+
+# Linux kernel, Symlink/Hardlink Attack
+
+Even though not directly comparable, the issues described at [Symlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink_Protection)
+and [Hardlink
+Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection)
+do bear some similarity with the issue we're discussing here.
diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn
index 8b08ef1e..40222f78 100644
--- a/open_issues/xattr.mdwn
+++ b/open_issues/xattr.mdwn
@@ -23,5 +23,14 @@ IRC, freenode, #hurd, 2011-06-01
       these instead of our Hurd-specific passive translator information in
       inodes.
 
-If interested in working on this, see [[!GNU_Savannah_task
-#5503]]/[[!GNU_Savannah_patch #5126]], and talk to [[tschwinge]].
+If interested in working on this, talk to [[tschwinge]], and see these resources:
+
+  * [[!GNU_Savannah_task 5503]], [[!GNU_Savannah_patch 5126]]
+
+  * <http://lists.gnu.org/archive/html/bug-hurd/2006-02/threads.html#00115>,
+    <http://lists.gnu.org/archive/html/bug-hurd/2006-01/threads.html#00180>,
+    <http://lists.gnu.org/archive/html/bug-hurd/2006-05/threads.html#00042>
+
+  * <http://www.spinics.net/lists/linux-ext4/msg07260.html>,
+    <http://www.spinics.net/lists/linux-ext4/msg07259.html>,
+    <http://www.spinics.net/lists/linux-ext4/msg07261.html>