Merge remote-tracking branch 'fp/master'

Conflicts:
	hurd.mdwn
	hurd/debugging/rpctrace.mdwn
	open_issues/clock_gettime.mdwn
	open_issues/time.mdwn

24 files changed, 841 insertions, 23 deletions

diff --git a/community/gsoc/project_ideas/smp.mdwn b/community/gsoc/project_ideas/smp.mdwn
index d9788e56..c6da2c41 100644
--- a/community/gsoc/project_ideas/smp.mdwn
+++ b/community/gsoc/project_ideas/smp.mdwn
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="SMP"]]
 
+See also the [[FAQ entry|faq/smp]].
+
 
 # IRC, freenode, #hurd, 2012-09-30
 
@@ -19,3 +21,12 @@ License|/fdl]]."]]"""]]
 ## IRC, freenode, #hurd, 2013-01-02
 
     <braunr> i'd like to mentor someone for adding smp to gnumach
+
+
+## IRC, freenode, #hurd, 2013-03-14
+
+    <braunr> but i'm afraid we'll have to fight obscur smp-safety issues
+    <braunr> for one, drivers are much probably not smp safe and would require
+      a big kernel lock
+    <braunr> userspace (such as signal delivery in libc) might be affected too
+    <braunr> smp isn't that easy
diff --git a/faq/support/smp.mdwn b/faq/support/smp.mdwn
index e95edcd2..04396401 100644
--- a/faq/support/smp.mdwn
+++ b/faq/support/smp.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2011, 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
@@ -26,3 +27,5 @@ That is why for now GNU/Hurd will only use one logical processor (i.e. one core
 
 Once this issue is solved, there are follow-up issues about
 [[open_issues/multiprocessing]] and [[open_issues/multithreading]].
+
+[[GSoC project idea|gsoc/project_ideas/smp]].
diff --git a/hurd.mdwn b/hurd.mdwn
index f005bd6b..ed88f09f 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -94,6 +94,7 @@ in the *unstable* branch of the Debian archive.
   * [[libihash]]
   * [[libpthread]]
   * [[libfshelp]]
+  * [[libps]]
 * In-development Libraries
   * [[libfuse]]
 * Discontinued Libraries
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index e7fa81ec..a5c1a6e9 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -175,8 +175,12 @@ See `rpctrace --help` about how to use it.
           /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
           trace_and_forward: Assertion `reply_type == 18' failed.
 
-This assertion is actually caused by using the io_select interface, which creates
-a send right instead of a send-once right for the reply port (IIRC).
+    This assertion is actually caused by using the io_select interface, which creates
+    a send right instead of a send-once right for the reply port (IIRC).
+
+      * IRC, OFTC, #debian-hurd, 2013-03-14
+
+            <youpi> uhu, there's a TODO just above that assertion :)
 
 
 # See Also
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index d6b8e8b6..be20fa58 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 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
@@ -19,19 +19,26 @@ License|/fdl]]."]]"""]]
 
   * hurd-l4 libhurd-ihash
 
+
+# Open Issues
+
   * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]]
 
-    IRC, unknown channel, unknown date
+    IRC, freenode, #hurd, 2008/2009
 
         <neal> so, we need a new ihash implementation
         <neal> marcusb: When 80% full, the collision rate is very high.
         <neal> marcusb: I tested using 512mb / 4096 entries
-        <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster.
+        <neal> marcusb: Changing the load factor to 30% resulted in my program
+          running more than an order of magnitude faster.
         <marcusb> yeah, it shouldn't get so full
         <marcusb> don't we do an exponential back-off in the array size?
         <marcusb> of course it's clear we can do much better
         <marcusb> the ihash algo is very simple
-        <marcusb> I'm not even sure it makes much sense to have a generic library
+        <marcusb> I'm not even sure it makes much sense to have a generic
+          library
+
+  * [[community/gsoc/project_ideas/object_lookups]]
 
 
 # Alternatives?
diff --git a/hurd/libps.mdwn b/hurd/libps.mdwn
new file mode 100644
index 00000000..05ab3ad1
--- /dev/null
+++ b/hurd/libps.mdwn
@@ -0,0 +1,27 @@
+[[!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]]."]]"""]]
+
+`libps` provides an API for accessing process information.  An alternative is a
+[[Linux-compatible `/proc` filesystem|translator/procfs]].
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-09
+
+[[!tag open_issue_documentation]]
+
+    <Steap> what's the difference between PSTAT_STATE_P_STOP and
+      PSTAT_STATE_T_HALT in libps/ps.h ?
+    <youpi> Steap: from reading the gnumach source, it seems halted threads are
+      thread which have finished they work but not finished terminating yet
+    <youpi> while STOP is the standard preempted state
+    <youpi> i.e. not sleeping, but have handed cpu to another thread
+    <Steap> youpi: thanks. Is this "halted" state similar to anything in Linux
+      ?
+    <youpi> TASK_DEAD, probably
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index bc43644f..a89b40b1 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -89,6 +89,37 @@ small backend stores, like floppy devices.
     <youpi> which can be quite probable
 
 
+##### IRC, freenode, #hurd, 2013-03-19
+
+    <braunr> youpi: i'm back on polishing the large store patch
+    <braunr> did you remember seeing something else than the bzero/memset
+      out-of-scope changes ?
+    <braunr> (i mean, readily noticeable)
+    <youpi> I don't remember
+    <braunr> ok
+    <braunr> the original code already assumes mmap succeeds
+    <braunr> is it ok to consider the patch can do the same ?
+    <youpi> I'd say so
+    <braunr> ok
+    <braunr> youpi: actually, it looks like a good part of the patch isn't
+      related to large stores
+    <braunr> for example, in ext2fs/inode.c, there are calls to
+      dino_ref/dino_deref
+    <youpi> hum
+    <braunr> i'm not sure at all these have anything to do with handling large
+      stores
+    <youpi> but dino_ref is introduced by this patch, isn't it?
+    <braunr> it replaces dino
+    <youpi> yes, it replaces it because the dino() approach can't work beyond
+      2GiB
+    <braunr> i see
+    <braunr> youpi: i'd like to replace the recursive call to
+      disk_cache_block_ref with a goto, is that fine with you ?
+    <youpi> looks ok to me
+    <youpi> better than relying on tail recursion
+    <braunr> that's the idea :)
+
+
 #### [[libpager]] API change
 
 ##### IRC, freenode, #hurd, 2013-03-04
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 50b5dfc2..3232e0cc 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -1,13 +1,58 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 The `pfinet` server is a hacked Linux internet implementation with a glue layer
 translating between the Hurd [[RPC]]s and the middle layer of the Linux
 implementation.
+
+
+# Bugs
+
+## Those Listed on [[Open_Issues]]
+
+## [[IPv6]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+    <braunr> youpi: there are indeed historical bugs with small packets and
+      tcp_nodelay in linux 2.0/2.2 tcp/ip
+    <youpi> oh
+    <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
+
+
+# Reimplementation, [[!GNU_Savannah_task 5469]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+[[!tag open_issue_hurd]]
+
+    <youpi> I was thinking about just using liblwip this afternoon, btw
+    <braunr> what is it ?
+    <braunr> hm, why not
+    <braunr> i would still prefer using code from netbsd
+    <braunr> especially now with the rump kernel project making it even easier
+    <youpi> well, whatever is easy to maintain up to date actually
+    <braunr> netbsd's focus on general portability normally makes it easy to
+      maintain
+    <braunr> the author of the rump project was able to make netbsd code run in
+      browsers :)
+    <braunr> and he actually showed clients using the networking stack on
+      windows, remotely (not in the same process)
+    <braunr> so that's very close to what we want
+    <youpi> indeed
+    <youpi> though liblwip is exactly the same portability focus :)
+    <braunr> apparently, for embedded systems
+    <youpi> but bsd's code is probably better
+    <youpi> yes
+    <braunr> i think so, more general purpose, larger user base
+    <youpi> I used it for the stubdomains in Xen
+    <youpi> (it = lwip)
+    <braunr> ok
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 79e8f05b..81826e00 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -147,3 +147,17 @@ Indeed, IPv6 now works properly, and the very machine hosting this wiki
     <youpi> I don't remember its url
     <braunr> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
     <braunr> might be even older
+
+
+## IRC, freenode, #hurd, 2013-04-01
+
+    <congzhan`> hi, the ipv6 route works or not?
+    <congzhan`> I can use ipv6 to connect vms, but the vm can't access other
+      host except the router
+    <congzhan`> the ipv6 route -G seems not work for me, anyone make it work?
+    <youpi> I'm using SLAAC
+    <congzhan`> youpi: you mean static config not work?
+    <youpi> I mean automatic config does work
+    <youpi> I don't use static config myself
+    <congzhang> youpi: My ipv6 works now, just because not fully enable ipv6
+      forwarding and firewall, thank you:)
diff --git a/hurd/translator/tarfs.mdwn b/hurd/translator/tarfs.mdwn
index 4cc5f57a..3eb7b1ed 100644
--- a/hurd/translator/tarfs.mdwn
+++ b/hurd/translator/tarfs.mdwn
@@ -20,6 +20,21 @@ Works fine on most cases, occasional corruptions when writing using bzip2/gzip
 stores.
 
 
+## IRC, freenode, #hurd, 2013-03-16
+
+[[!tag open_issue_hurd]]
+
+    <pinotree> hm is tarfs working? its simple test suite fails here
+      (translator dies with gz and bz2 compression)
+    <braunr> no idea
+    <braunr> have you tried without compression ?
+    <pinotree> that succeeds
+    <braunr> it might rely on storeio for compression
+    <pinotree> no, it does gz/bz2 on its own
+    <pinotree> but it uses libstore for i/o of the file
+    <braunr> ok
+
+
 # Source
 
 [[source_repositories/incubator]], tarfs/master
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index b3e1758c..dcabb56e 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -615,3 +615,139 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
       way it is in mach and netbsd
     <braunr> but the arch-specific interfaces aren't well defined yet because
       there is only one (and incomplete) arch
+
+
+### IRC, freenode, #hurd, 2013-03-08
+
+    <antrik> BTW, what is your current direction? did you follow through with
+      abandonning Mach resemblance?...
+    <braunr> no
+    <braunr> it's very similar to mach in many ways
+    <braunr> unless mach is defined by its ipc in which case it's not mach at
+      all
+    <braunr> the ipc interface will be similar to the qnx one
+    <antrik> well, Mach is pretty much defined by it's IPC and VM interface...
+    <braunr> the vm interface remains
+    <antrik> its
+    <braunr> although vm maps will be first class objects
+    <braunr> so that it will be possible to move parts of the vm server outside
+      the kernel some day if it feels like a good thing to do
+    <braunr> i.e. vm maps won't be inferred from tasks
+    <braunr> not implicitely
+    <braunr> the kernel will be restricted to scheduling, memory management,
+      and ipc, much as mach is (notwithstanding drivers)
+    <antrik> hm... going with QNX IPC still seems risky to me... it's designed
+      for simple embedded environments, not for general-purpose operating
+      systems in my understanding
+    <braunr> no, the qnx ipc interface is very generic
+    <braunr> they can already call remote services
+    <braunr> the system can scale well on multiprocessor machines
+    <braunr> that's not risky at all, on the contrary
+    <antrik> yeah, I'm sure it's generic... but I don't think anybody tried to
+      build a Hurd-like system on top of it; so it's not at all clear whether
+      it will work out at all...
+    <auronandace> clueless question: does x15 have any inspiration from
+      helenos?
+    <braunr> absolutely none
+    <braunr> i'd say x15 is almost an opposite to helenos
+    <braunr> it's meant as a foundation for unix systems, like mach
+    <braunr> some unix interfaces considered insane by helenos people (such as
+      fork and signals) will be implemented (although not completely in the
+      kernel)
+    <braunr> ipc will be mostly synchronous
+    <braunr> they're very different
+    <braunr> well, helenos is very different
+    <auronandace> cool
+    <braunr> x15 and actually propel (the current name i have for the final
+      system), are meant to create a hurd clone
+    <auronandace> another clueless question: any similarities of x15 to minix?
+    <braunr> and since we're few, implementing posix efficiently is a priority
+      goal for me
+    <braunr> again, absolutely none
+    <braunr> for the same reasons
+    <braunr> minix targets resilience in embedded environments
+    <braunr> propel is a hurd clone
+    <braunr> propel aims at being a very scalable and performant hurd clone
+    <braunr> that's all
+    <auronandace> neato
+    <braunr> unfortunately, i couldn't find a name retaining all the cool
+      properties of the hurd
+    <braunr> feel free to suggest ideas :)
+    <auronandace> propel? as in to launch forward?
+    <braunr> push forward, yes
+    <auronandace> that's very likely a better name than anything i could
+      conjure up
+    <braunr> x15 is named after mach (the first aircraft to break mach 4,
+      reaching a bit less than mach 7)
+    <braunr> servers will be engines, and together to push the system forward
+      ..... :)
+    <auronandace> nice
+    <auronandace> thrust might be a bit too generic i guess
+    <braunr> oh i'm looking for something like "hurd"
+    <braunr> doubly recursive acronym, related to gnu
+    <braunr> and short, so it can be used as a c namespace
+    <braunr> antrik: i've thought about it a lot, and i'm convinced this kind
+      of interface is fine for a hurd like system
+    <braunr> the various discussions i found about the hurd requirements
+      (remember roland talking about notifications) all went in this direction
+    <braunr> note however the interface isn't completely synchronous
+    <braunr> and that's very important
+    <antrik> well, I'm certainly curious. but if you are serious about this,
+      you'd better start building a prototype as soon as possible, rather than
+      perfecting SMP ;-)
+    <braunr> i'm not perfecting smp
+    <braunr> but i consider it very important to have migrations and preemption
+      actually working before starting the prototype
+    <braunr> so that tricky mistakes about concurrency can be catched early
+    <antrik> my current hunch is that you are trying to do too much at the same
+      time... improving both the implementation details and redoing the system
+      design
+    <braunr> so, for example, there is (or will be soon, actually) thread
+      migratio, but the scheduler doesn't take processor topology into account
+    <braunr> that's why i'm starting from scratch
+    <braunr> i don't delve too deep into the details
+    <braunr> just the ones i consider very important
+    <antrik> what do you mean by thread migration here? didn't you say you
+      don't even have IPC?...
+    <braunr> i mean migration between cpus
+    <antrik> OK
+    <braunr> the other is too confusing
+    <braunr> and far too unused and unknown to be used
+    <braunr> and i won't actually implement it the way it was done in mach
+    <braunr> again, it will be similar to qnx
+    <antrik> oh? now that's news for me :-)
+    <antrik> you seemed pretty hooked on thread migration when we talked about
+      these things last time...
+    <braunr> i still am
+    <braunr> i'm just saying it won't be implemented the same way
+    <braunr> instead of upcalls from the kernel into userspace, i'll "simply"
+      make server threads inherit from the caller's scheduling context
+    <braunr> the ideas i had about stack management are impossible to apply in
+      practice
+    <braunr> which make the benefit i imagined unrealistic
+    <braunr> and the whole idea was very confusing when compared and integrated
+      into a unix like view
+    <braunr> so stack usage will be increased
+    <braunr> that's ok
+    <antrik> but thread migration is more or less equivalent with first-class
+      RPCs AIUI. does that work with the QNX IPC model?...
+    <braunr> the very important property that threads don't block and wake a
+      server when sending, and the server again blocks and wake the client on
+      reply, is preserved
+    <antrik> (in fact I find the term "first-class RPC" much clearer...)
+    <braunr> i dont
+    <braunr> there are two benefits in practice: since the scheduling context
+      is inherited, the client is charged for the cpu time consumed
+    <braunr> and since there are no wakeups and blockings, but a direct hand
+      off in the scheduler, the cost of crossing task space is closer to the
+      system call
+    <antrik> which can be problematic too... but still it's the solution chosen
+      by EROS for example AIUI
+    <antrik> (inheriting scheduling contexts I mean)
+    <braunr> by practically all modern microkernel based systems actually, as
+      noted by shapiro
+    <antrik> braunr: well, both benefits can be achieved by other means as
+      well... scheduler activations like in Viengoos should handle the hand-off
+      part AIUI, and scheduling contexts can be inherited explicitly too, like
+      in EROS (and in a way in Viengoos)
+    <braunr> i don't understand viengoos well enough to do it that way
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index ebb48e24..677e4625 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -351,3 +351,32 @@ Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and l
     <braunr>
       http://en.wikipedia.org/wiki/List_of_important_publications_in_computer_science#Operating_systems
       should be a pretty good list :)
+
+
+# IRC, freenode, #hurd, 2013-03-12
+
+    <mjjc> i have a question regarding ipc in hurd. if a task is created, does
+      it contain any default port rights in its space? i am trying to deduce
+      how one calls dir_lookup() on the root translator in glibc's open().
+    <kilobug> mjjc: yes, there are some default port rights, but I don't
+      remember the details :/
+    <mjjc> kilobug: do you know where i should search for details?
+    <kilobug> mjjc: hum either in the Hurd's hacking guide
+      https://www.gnu.org/software/hurd/hacking-guide/ or directly in the
+      source code of exec server/libc I would say, or just ask again the
+      question here later on to see if someone else has more information
+    <mjjc> ok, thanks
+    <pinotree> there's also rpctrace to, as the name says, trace all the rpc's
+      executed
+    <braunr> some ports are introduced in new tasks, yes
+    <braunr> see
+      http://www.gnu.org/software/hurd/hacking-guide/hhg.html#The-main-function
+    <braunr> and
+    <braunr>
+      http://www.gnu.org/software/hurd/gnumach-doc/Task-Special-Ports.html#Task-Special-Ports
+    <mjjc> yes, the second link was just what i was looking for, thanks
+    <braunr> the second is very general
+    <braunr> also, the first applies to translators only
+    <braunr> if you're looking for how to do it for a non-translator
+      application, the answer is probably somewhere in glibc
+    <braunr> _hurd_startup i'd guess
diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn
index 3caa6c28..5ba6b418 100644
--- a/open_issues/clock_gettime.mdwn
+++ b/open_issues/clock_gettime.mdwn
@@ -188,4 +188,13 @@ In context of [[select]].
     <youpi> and we'll make that a 64bit struct when we have a64bit userland
 
 
+# IRC, freenode, #hurd, 2013-04-06
+
+    <tschwinge> pinotree: You had once been working on adding nsec-procision
+      timestamps to GNU Mach's maptime interface (or what the name is).  Is
+      that blocked on something or just waiting to be continued?
+    <pinotree> blocked on me needing to learn more the proper way to do
+      "atomic" update of the struct with time :)
+
+
 # Candidate for [[vDSO]] code?
diff --git a/open_issues/glibc/debian/experimental.mdwn b/open_issues/glibc/debian/experimental.mdwn
new file mode 100644
index 00000000..8d117e99
--- /dev/null
+++ b/open_issues/glibc/debian/experimental.mdwn
@@ -0,0 +1,115 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_glibc]]
+
+Issues with the current 2.17 version of glibc/EGLIBC in Debian experimental.
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-14
+
+    <markus_w1nner> I have a strange tcp via localhost question:
+    <markus_wanner> The other side closes the connection, but I haven't read
+      all data, yet. I should still be able to read the pending data, no?
+    <markus_wanner> At least it seems to work that way on Linux, but not on
+      Hurd.
+    <markus_wanner> Got a simple repro with nc, if you're interested...
+    <youpi> markus_wanner: yes, we're interested
+    <markus_wanner> youpi: okay, here we go:
+    <markus_wanner> session 1: nc -l -p 7777 localhost
+    <markus_wanner> session 2: nc 127.0.0.1 7777
+    <markus_wanner> session 2: a <RET> b <RET> c <RET>
+    <markus_wanner> session 1: [ pause with Ctrl-Z ]
+    <markus_wanner> session 2: [ send more data ] d <RET> e <RET> f <RET>
+    <markus_wanner> session 2: [ quit with Ctrl-C ]
+    <markus_wanner> session 1: [ resume with 'fg' ]
+    <markus_wanner> The server on session 1 doesn't get the data sent after it
+      paused and before the client closed the connection.
+    <markus_wanner> I'm not sure if that's a valid TCP thing. However, on
+      Linux, the server still gets the data. On hurd it doesn't.
+    <markus_wanner> I'm working on a C-code test case, ATM.
+    <youpi> markus_wanner: on which box are you seeing this behavior?
+    <youpi> exodar does not have it
+    <youpi> i.e. I do get the d e f
+    <markus_wanner> a private VM (I'm not a DD)
+    <markus_wanner> ..updated to latest experimental stuff.
+    <markus_wanner> GNU lematur 0.3 GNU-Mach 1.3.99-486/Hurd-0.3 i686-AT386 GNU
+    <youpi> ok, I can't reproduce it on my vm either
+    <youpi> maybe the C program will help
+    <markus_wanner> Hm.. cannot corrently reproduce that in C. (Netcat still
+      shows the issue, though).
+    <markus_wanner> I'll try to strace netcat...
+    <markus_wanner> ..Meh. strace not available on Hurd?
+    <pinotree> no, but there is rpctrace to show the various rpc
+    <markus_wanner> Cool, looks helpful.
+    <markus_wanner> Thx
+    <markus_wanner> Uh.. that introduces another error:
+    <markus_wanner> rpctrace: ../../utils/rpctrace.c:1287: trace_and_forward:
+      Assertion `reply_type == 18' failed.
+
+[[hurd/debugging/rpctrace]].
+
+    <youpi> I'm checking on a box without ipv6 configuration
+    <youpi> maybe that's the difference between you and me
+    <youpi> I guess your /etc/alternatives/nc is /bin/nc.traditional ?
+    <markus_wanner> Yup, nc.traditional.
+    <markus_wanner> Looks like that box only has IPv4 configured.
+    <markus_wanner> Something very strange is going on here. No matter how hard
+      I try, I cannot reproduce this with netcat, anymore.
+    <pinotree> not even after a reboot?
+    <markus_wanner> Woo.. here, it happened, again! This is driving me crazy!
+    <markus_wanner> Now, nc seemingly connects, but is unable to send data
+      between the two. Netcat would somehow complain, if it failed to connect,
+      no?
+    <markus_wanner> No it worked.
+    <markus_wanner> So this seems to be an intermittent issue. So far, I could
+      only ever repro it as a normal user, not as root. May be coincidental,
+      though.
+    <markus_wanner> Now, 'a' and 'b' made it through, but not the 'c' sent
+      manually just after that. Something with that TCP/IP stack is definitely
+      fishy.
+    <markus_wanner> Anything I can try to investigate? Or shall I simply
+      restart and see if the problem persists?
+    <youpi> maybe restart, yes
+    <youpi> did you restart since the upgrade ?
+    <markus_wanner> Yes, I restarted after that.
+    <markus_wanner> Hm.. okay, restarted. Some problem persists.
+    <markus_wanner> I currently have two netcat processes connected, the
+      listening one got some first two messages and seems stuck now.
+    <markus_wanner> With the client, I tried to send more data, but the server
+      doesn't get it, anymore.
+    <markus_wanner> Any idea on what I can do to analyze the situation?
+    <youpi> for the netcat issue, I haven't experienced this
+    <youpi> are you running in kvm or virtualbox or something else?
+    <markus_wanner> I'm currently puzzled about what "experimental" actually
+      ships.
+    <markus_wanner> On kvm.
+    <markus_wanner> My libc0.3 used to be 2.13-39+hurd.3.
+    <markus_wanner> But packages.d.o already shows 2.17.0experimental2.
+    <youpi> experimental ships experimental versions, which you aren't supposed
+      to use
+    <youpi> unless you know what you are doing
+    <youpi> iirc 2.17 is known to be quite broken for now
+    <markus_wanner> Okay. So I guess I'll try to "downgrade" to unstable, then.
+    <markus_wanner> Phew, okay, successfully downgraded to unstable.
+    <markus_wanner> Hopefully monotone's test suite runs through fine, now.
+    <markus_wanner> Yup, WORKING! Looks like some experimental packages caused
+      the problem. The netcat test as well as that one failing monotone test
+      work fine, now.
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-19
+
+    <tschwinge> pinotree, youpi: Is there anything from that markus_wanner
+      discussion about pfinet/netcat/signals that needs to be filed?  I guess
+      we don't know what exactly he changed so that everything workedd fine
+      eventually?  (Some experimental package(s), but which?)
+    <youpi> that was libc0.3 packages
+    <youpi> which are indeed known to break the network
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index d0ec4119..28532320 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1281,6 +1281,19 @@ Most of the issues raised on this page has been resolved, a few remain.
     <braunr> weird sentence, agreed :p
 
 
+### IRC, freenode, #hurd, 2013-03-11
+
+    <braunr> youpi: oh btw, i noticed a problem with the priority adjustement
+      code
+    <braunr> a thread created by a privileged server (e.g. an ext2fs
+      translator) can then spawn a server from a node owned by an unprivileged
+      user
+    <braunr> which inherits the priority
+    <braunr> easy to fix but worth saying to keep in mind
+    <youpi> uh
+    <youpi> indeed
+
+
 ## IRC, freenode, #hurd, 2012-12-05
 
     <braunr> tschwinge: i'm currently working on a few easy bugs and i have
diff --git a/open_issues/linux_vmsig.mdwn b/open_issues/linux_vmsig.mdwn
index a4311d3e..182fb6f9 100644
--- a/open_issues/linux_vmsig.mdwn
+++ b/open_issues/linux_vmsig.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -27,3 +27,18 @@ From a quick glance, this sounds to [[me|tschwinge]] quite a bit like
 mechanisms also found in (originating in?) Mach's
 [[microkernel/mach/external_pager_mechanism]].  May be worth having a look at
 it.
+
+
+# IRC, freenode, #hurd, 2013-03-06
+
+    <braunr> tschwinge: from a quick look, this isn't similar to the external
+      pager mechanism
+    <braunr> it's an additional tool to help userspace application manage
+      internal caches
+    <braunr> it's similar to what is done to reclaim memory from the slab
+      allocator for example
+    <braunr> and it would indeed be a very good thing to have so that e.g. the
+      hurd can build a distributed but completely dynamic dentry-like cache
+    <braunr> i'm actually glad to see someone else thought of using real time
+      signals for this
+    <braunr> i didn't do any research on that subject yet
diff --git a/open_issues/managed_runtime_initiative.mdwn b/open_issues/managed_runtime_initiative.mdwn
new file mode 100644
index 00000000..7a880beb
--- /dev/null
+++ b/open_issues/managed_runtime_initiative.mdwn
@@ -0,0 +1,72 @@
+[[!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]]."]]"""]]
+
+[[!tag open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2013-04-02
+
+    <psockali> hi again, maybe someone has some metrics 
+    <psockali> is mprotect / munprotect faster in hurd then in linux ?
+    <pinotree> ?
+    <psockali> can i protected a memory page against write access in hurd 
+    <psockali> and if so, is it a fast operation ?
+    <youpi> you can, I never measured, but it's probably the same cost as in
+      linux
+    <youpi> I don't see why it would be different, as it boils down to the same
+      x86 trick
+    <psockali> but i suppose it is part of the mach kernel doing the protection
+      and not part of the unix layer ?
+    <youpi> it is
+    <youpi> the unix layer doesn't have mm control
+    <youpi> it has to ask the kernel
+    <braunr> it's slower on mach, as it's less optimized because of historical
+      reasons
+    <braunr> but that's about it
+    <youpi> less optimized, how so?
+    <braunr> well, more entry fragmentation
+    <youpi> in the end you mark the page table and flush the tlb
+    <braunr> yes
+    <braunr> the high level virtual memory layer is a bit slower
+    <youpi> but fragmentation doesn't come into play it you just have one
+      memory object, does it?
+    <braunr> it does, as it's about memory areas, not objects
+    <braunr> the object is merely a backing store
+    <braunr> protection, inheritance, copy on write are all area (vm_map_entry)
+      attributes
+    <braunr> also, some operations affect all the address spaces where a
+      physical page is mapped
+    <braunr> although i think linux does the same thing as mach/bsd now
+    <youpi> but mprotect/munprotect doesn't, does it?
+    <braunr> no
+    <braunr> or perhaps by side effect, in some situations, i'm not sure
+    <braunr> i think it depends if the memory is shared between processes, but
+      i don't remember the details and can't think of a proper example right
+      now
+    <braunr> but anyway, "slower" here is negligible unless address spaces are
+      really huge and filled with lots of map entries
+    <braunr> psockali: why do you ask ?
+    <psockali> can i post a link here ?
+    <braunr> about what ?
+    <psockali> it's regarding azul / managed runtime initiative 
+    <psockali> a GC for java
+    <braunr> why not
+    <braunr> although i don't see the point for now :)
+    <psockali> they have a custom MM management module for their GC as linux
+      kernel modul
+    <psockali> and i was wondering if mach would be any faster then linux in
+      that aspect
+    <psockali>
+      http://stackoverflow.com/questions/3358545/whats-actually-in-the-managed-runtime-initiatives-kernel-patches-and-jvm
+    <braunr> psockali: generally speaking, mach is slower than linux because of
+      its age and the fact it didn't receive as much attention and
+      microoptimization as linux did
+    <braunr> psockali: about this article, there is no reason mach would be
+      faster
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index d7804864..03614fae 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -354,6 +354,33 @@ Tom Van Cutsem, 2009.
 [[hurd/libpager]].
 
 
+### IRC, freenode, #hurd, 2013-03-29
+
+    <braunr> some day i'd like to add a system call that threads can use to
+      terminate themselves, passing their stack as a parameter for deallocation
+    <braunr> then, we should review the timeouts used with libports management
+    <braunr> having servers go away when unneeded is a valuable and visible
+      feature of modularity
+
+
+### IRC, freenode, #hurd, 2013-04-03
+
+    <braunr> youpi: i also run without the libports_stability patch
+    <braunr> and i'd like it to be removed unless you still have a good reason
+      to keep it around
+    <youpi> well, the reason I know is mentioned in the patch
+    <youpi> i.e. the box becomes unresponsive when all these threads wake up at
+      the same time
+    <youpi> maybe we could just introduce some randomness in the sleep time
+    <braunr> youpi: i didn't experience the problem
+    <youpi> well, I did :)
+    <braunr> or if i did, it was very short
+    <youpi> for the libports stability, I'd really say take a random value
+      between timeout/2 and timeout
+    <youpi> and that should just nicely fix the issue
+    <braunr> ok
+
+
 ## Alternative approaches:
 
   * <http://www.concurrencykit.org/>
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
index e27d3018..1f4c6ab8 100644
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -387,3 +387,43 @@ here.
     <youpi> the issue is mach not supporting enough sched levels
     <youpi> can be fixed, of course
     <youpi> just nobody did yet
+
+GNU Mach commit 6a234201081156e6d5742e7eeabb68418b518fad (and commit
+6fe36b76f7983ec9a2e8a70420e431d54252442e).
+
+
+## IRC, OFTC, #debian-hurd, 2013-03-07
+
+    <braunr> youpi: btw, why did you increase the number of priorites to 50 ?
+    <youpi> for the nice levels
+    <braunr> and probably something more, there are only 40 nice levels
+    <youpi> yes, the current computation leaves some margin
+    <youpi> so I preferred to keep a margin too
+    <braunr> ok
+    <youpi> e.g. for the idle thread, etc.
+    <braunr> or interrupt threads
+    <youpi> yep
+    <braunr> i see the point, thanks
+    <tschwinge> Is the number of 40 specified by POSIX (or whatever) or is that
+      a Linuxism?
+    <braunr> good question
+    <braunr> posix is weird when it comes to such old unixisms
+    <braunr> there is a NZERO value, but i don't remember how it's specified
+    <youpi> it's at least 20
+    <tschwinge> (I don't object to the change; just wondered.  And if practice,
+      you probably wouldn't really need more than a handful.  But if that
+      change (plus some follow-up in glibc (?) improves something while not
+      adding a lot of overhead, then that's entirely fine, of course.)
+    <braunr> "A maximum nice value of 2*{NZERO}-1 and a minimum nice value of 0
+      shall be imposed by the system"
+    <braunr> NZERO being 20 by default
+    <youpi> and 20 is the minimum for NZERO too
+    <braunr> hm, not the default, the minimul
+    <braunr> minimum
+    <braunr> yes that's it
+    <braunr> ok so it's actually well specified
+    <tschwinge> Aha, I see (just read it, too).  So before that change we
+      simply couldn't satisfy the POSIX requirement of (minimum) NZERO = 20,
+      and allowing for step-1 increments.  Alright.
+    <youpi> yep
+    <youpi> thus failing in coreutils testsuite
diff --git a/open_issues/performance/io_system/read-ahead.mdwn b/open_issues/performance/io_system/read-ahead.mdwn
index 8a8ba823..768dca93 100644
--- a/open_issues/performance/io_system/read-ahead.mdwn
+++ b/open_issues/performance/io_system/read-ahead.mdwn
@@ -2989,3 +2989,45 @@ License|/fdl]]."]]"""]]
       determine what m_o_ function will be used
     <mcsim> now default_read calls m_o_ on its own
     <braunr> ok
+
+
+## IRC, freenode, #hurd, 2013-03-06
+
+    <mcsim> braunr: hi, regarding memory policies. Should I create separate
+      policy that will do pageout or VM_ADVICE_SEQUENTIAL is good enough?
+    <mcsim> braunr: at the moment it is exactly like NORMAL 
+    <braunr> mcsim: i thought you only did pageins
+    <mcsim> braunr: yes, but I'm doing pageouts now
+    <braunr> oh
+    <braunr> i'd prefer you didn't :/
+    <braunr> if you want to improve paging, i have a suggestion i believe is a
+      lot better
+    <braunr> and we have 3 patches concerning libpager that we need to review,
+      polish, and merge in
+    <mcsim> braunr: That's not hard, and I think I know what to do
+    <braunr> yes i understand that
+    <braunr> but it may change the interface and conflict with the pending
+      changes
+    <mcsim> braunr: What changes?
+    <braunr> the large store patch, neal's libpager rework patch on top of
+      which you made your changes, and your changes
+    <braunr> the idea i have in mind was writeback throttling
+
+[[hurd/translator/ext2fs]], [[hurd/libpager]].
+
+    <braunr> i was planning on doing it myself but if you want to work on it,
+      feel free to
+    <braunr> it would be a much better improvement at this time than clustered
+      pageouts
+    <braunr> (which can then immediately follow
+    <braunr> )
+    <mcsim> braunr: ok
+    <mcsim> braunr: but this looks much more bigger task for me
+    <braunr> we'll talk about the strategy i had in mind tomorrow
+    <braunr> i hope you find it simple enough
+    <braunr> on the other hand, clustered pageouts are very similar to pageins
+    <braunr> and we have enough paging related changes to review that adding
+      another wouldn't be such a problem actually
+    <mcsim> so, add?
+    <braunr> if that's what you want to do, ok
+    <braunr> i'll think about your initial question tomorrow
diff --git a/open_issues/pfinet_timers.mdwn b/open_issues/pfinet_timers.mdwn
index 387ad4fe..5db192e3 100644
--- a/open_issues/pfinet_timers.mdwn
+++ b/open_issues/pfinet_timers.mdwn
@@ -15,3 +15,105 @@ License|/fdl]]."]]"""]]
 
     <braunr> now that there is a pthread_hurd_cond_timedwait_np function
       available, we could replace the ulgy timers in pfinet
+
+
+# IRC, freenode, #hurd, 2013-04-02
+
+    <braunr> youpi: also, i think i know why fakeroot is slow on the hurd
+    <braunr> well, pfinet actually
+    <youpi> tcp flow control?
+    <braunr> i think it's because of our timer resolution
+    <youpi> ah
+    <braunr> and i think i spotted a small mistake in the timer emulation code
+      btw
+    <braunr> it's so obvious i even doubt it's actually true :)
+    <braunr> see timer_emul.c:timer_function
+    <braunr> the code checks for timers->expires < jiffies
+    <braunr> shouldn't it be "<="
+    <braunr> ?
+    <youpi> well it'd be equivalent
+    <youpi> if ==, then wait becomes 0 in the else
+    <braunr> see the second scheck
+    <braunr> the one performed right before running the callback
+    <youpi> ah, the while?
+    <braunr> yes
+    <youpi> I'd say <= could do it yes
+    <braunr> ok
+    <braunr> i have hurd packages ready to be tested
+    <youpi> although I'm unsure it'd make a difference
+    <youpi> do you notice some?
+    <braunr> just waiting for my current glibc to finish building
+    <braunr> and i'll test right after
+    <braunr> i think it would actually
+    <youpi> in which case?
+    <braunr> the timer resolution is 10ms
+    <braunr> it's huge
+    <braunr> well, i hope it fixes fakeroot slowness :)
+    <youpi> so timers below that would trigger immediately?
+    <braunr> or equal
+    <braunr> taht's the problem
+    <braunr> for 10ms, timers that have expired must wait for the next tick to
+      fire
+    <youpi> I include "equal" in below
+    <youpi> actually :)
+    <braunr> then yes :)
+    <braunr> soryy i never know when equal is implicit
+    <youpi> because they boil down to expires = jiffies
+    <youpi> in french it's implicit
+    <youpi> but anyway here equal is not really important
+    <braunr> right
+    <braunr> why ?
+    <youpi> it's the fact that 1ms would be rounded up to 10ms, not down to 0ms
+    <braunr> well, doing that seems reasonable
+    <youpi> or rather, rounded down to 0ms, but waited for 10ms because of the
+      <
+    <braunr> we do want timers not to fire before the time event
+    <youpi> I'm however wondering which part of the code would have timer below
+      10ms
+    <braunr> well, a select with low timeout from a client perhaps ?
+    <youpi> but then we have to round up
+    <youpi> as you say we don't want to fire before some time
+    <braunr> well yes
+    <braunr> that's fine
+    <youpi> all that being said, linux has been having 10ms clock for a long
+      time
+    <braunr> but when the timer fires, i.e. when expires == jiffie, we do want
+      it to fire
+    <youpi> highres timers are only relativeley recent
+    <braunr> not at jiffie + 1
+    <youpi> braunr: ah, right, so we don't wait for 20ms instead of 10ms
+    <braunr> yes
+    <youpi> ok, so it's not a miracle fix, but could bring 2times fix
+    <braunr> well, pfinet eats 40% of my processor when this problem occurs
+    <braunr> which i'm seeing right now
+    <youpi> yes, I've seen that too
+    <braunr> so it may be a visible win
+    <braunr> build finished :) let's see
+    <youpi> Mmm, thinking again
+    <youpi> indeed
+    <youpi> when expires become jiffies
+    <youpi> we mach_msg (0)
+    <youpi> but don't do anything
+    <youpi> and then restart
+    <youpi> so just eaten cpu for nothing
+    <braunr> is there a small package that builds fast and uses fakeroot a lot
+      ?
+    <youpi> something like a package which has a lot of data to install at make
+      install
+    <braunr> or i can rebuild glibc with -nc
+    <youpi> ok, I've checked in linux
+    <pinotree> libarchive's testsuite used to intermittently failing under
+      fakeroot
+    <youpi> it's definitely <= which is meant
+    <braunr> it looks better
+    <braunr> but still not 100% cpu
+    <youpi> at any rate, as long as it doesn't seem to break anything, please
+      push the fix
+    <youpi> it definitely makes sense
+    <youpi> (and I don't see why it could break anything)
+    <braunr> ok
+    <braunr> i'll look into this timer problem a bit more, there may be other
+      code involved
+    <braunr> yes, schedule_timeout could need a review
+    <braunr> actually, fakeroot rm -rf * is a good test
+    <braunr> and it's still damn slow
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn
index bd9abcf9..0d786d2a 100644
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ b/open_issues/translate_fd_or_port_to_file_name.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 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
@@ -15,14 +16,17 @@ License|/fdl]]."]]"""]]
 
 # IRC, freenode, #hurd, June (?) 2010
 
-    <pochu> is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port?
+    <pochu> is there a way (POSIX or Hurdish) to get the corresponding file
+      name for a fd or a hurd port?
     <marcusb> there is a way
     <pochu> marcusb: which one would that be?
     <marcusb> I forgot
     <marcusb> there is an implementation in libc
     <marcusb> realpath has a similar job
     <marcusb> but that's not what I mean
-    <marcusb> pochu: maybe I am misremembering.  But it was something where you keep looking up .. and list that directory, looking for the node with the ID of the node you had .. for
+    <marcusb> pochu: maybe I am misremembering.  But it was something where you
+      keep looking up .. and list that directory, looking for the node with the
+      ID of the node you had .. for
     <marcusb> maybe it works only for directories
     <marcusb> yeah
     <marcusb> pochu: check the getcwd() implementation of libc
@@ -30,20 +34,25 @@ License|/fdl]]."]]"""]]
     <marcusb> _hurd_canonicalize_directory_name_internal 
     * pochu looks
     <pochu> marcusb: interesting
-    <pochu> though that is for dirs, and doesn't seem to be extensible to files, as you cannot lookup for ".." under a file
+    <pochu> though that is for dirs, and doesn't seem to be extensible to
+      files, as you cannot lookup for ".." under a file
     <marcusb> right
     <pochu> oh you already said that :)
     <marcusb> actually, I am not sure that's correct
-    <marcusb> it's probably correct, but there is no reason why looking .. up on a file couldn't return the directory it's contianed in
-    <pochu> I don't know the interfaces or the Hurd internals very well yet, but it would look strange to me if you could do that
+    <marcusb> it's probably correct, but there is no reason why looking .. up
+      on a file couldn't return the directory it's contianed in
+    <pochu> I don't know the interfaces or the Hurd internals very well yet,
+      but it would look strange to me if you could do that
     <marcusb> the hurd is strange
-    <pochu> it sounds like if you could `ls getcwd.c/..` to get sysdeps/mach/hurd/ :-)
+    <pochu> it sounds like if you could `ls getcwd.c/..` to get
+      sysdeps/mach/hurd/ :-)
     <marcusb> yep
     <pochu> ok. interesting
     <marcusb> you wouldn't find "ls foo.zip/.." very strange, wouldn't you?
     <pochu> I guess not if `ls foo.zip` listed the contents of foo.zip
     <marcusb> there you go
-    <marcusb> or the other way round: would you be surprised if "cat somedir" would work?
+    <marcusb> or the other way round: would you be surprised if "cat somedir"
+      would work?
     <pochu> I think so. if it did, what would it do?
     <marcusb> originally, cat dir would list the directory content!
     <marcusb> in the old unix times
@@ -51,10 +60,49 @@ License|/fdl]]."]]"""]]
     <marcusb> and some early BSDs 
     * pochu feels young :-)
     <marcusb> he don't worry, I didn't see those times either
-    <marcusb> technically, files and directories are implemented in the same way in the hurd, they both are objects implementing the fs.defs interface
+    <marcusb> technically, files and directories are implemented in the same
+      way in the hurd, they both are objects implementing the fs.defs interface
     <marcusb> which combines file and directory operations
-    <marcusb> of course, files and directories implement those functions differently
-    <antrik> marcusb: do you know why this behavior (cat on directories) was changed?
+    <marcusb> of course, files and directories implement those functions
+      differently
+    <antrik> marcusb: do you know why this behavior (cat on directories) was
+      changed?
+
+
+## IRC, freenode, #hurd, 2013-03-07
+
+    * pinotree ponders about sending as RFC his patch for /proc/$pid/maps
+    <tschwinge> Including a scheme for providing the names of mapped files?
+      ;-D
+    <braunr> that would be really great indeed
+    <tschwinge> I have not yet researched how Linux does this.  Perhaps store
+      the filename used for first opening a file as a string somewhere?
+    <pinotree> tschwinge: eh, indeed that's lacking in my patch
+    <braunr> i'm not sure we should aim at doing it the same way
+    <youpi> I was wondering about having interfaces for naming tasks, threads,
+      objects
+    <youpi> that'd be useful for debugging in general
+    <braunr> yes
+    <braunr> i don't think we need to take namespaces into account
+    <braunr> a simple name or path should be quite enough
+    <tschwinge> Agreed.  "Just something!"
+    <tschwinge> So, a Java toString() method for ports.
+    <tschwinge> ;-)
+    <braunr> yes
+    <tschwinge> Oh, and could this also work recursively?  The ext2fs instance
+      on /home asks its parent fs about its own path -- can it do that?  (And
+      then cache that, most likely?)  Would one get rooted filesnames that way?
+    <braunr> i really don't think we should link it to the VFS
+    <braunr> it should merely be a name for debugging
+    <youpi> yep, same for me
+    <youpi> I'd say it's the linker's task of just setting a sane name
+    <braunr> first, keeping it isolated prevents increasing complexity
+    <braunr> next, it doesn't reduce performance
+    <tschwinge> youpi: Linker?
+    <tschwinge> braunr: Ack.
+    <braunr> yes, ld is the one creating the mappings
+    <youpi> tschwinge: the one that loads libraries
+    <tschwinge> Ah, for /proc/*/maps, right.  I've been thinking more globally.
 
 
 # IRC, freenode, #hurd, 2011-07-13
diff --git a/open_issues/virtualization/fakeroot.mdwn b/open_issues/virtualization/fakeroot.mdwn
index ec762b59..f4739776 100644
--- a/open_issues/virtualization/fakeroot.mdwn
+++ b/open_issues/virtualization/fakeroot.mdwn
@@ -15,3 +15,10 @@ License|/fdl]]."]]"""]]
 
     <youpi> btw, about fakeroot-hurd
     <youpi> the remaining issue I see is with argv[0] (yes, again...)
+
+
+## IRC, freenode, #hurd, 2013-04-03
+
+    <youpi> btw, I believe our fakeroot-hurd is close to working actually
+    <youpi> it's just a argv[0] issue supposed to be fixed by exec_file_name
+      but apparently not fixed in that case, for some reason
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
index 67d64ae0..dcef310d 100644
--- a/open_issues/virtualization/remap_root_translator.mdwn
+++ b/open_issues/virtualization/remap_root_translator.mdwn
@@ -139,3 +139,8 @@ License|/fdl]]."]]"""]]
     <youpi> let me just comment out that :)
     <youpi> way better :)
     <youpi> yep, just works fine
+
+
+# IRC, freenode, #hurd, 2013-03-16
+
+    <braunr> youpi: is the /bin/remap --help output correct ?