Merge remote-tracking branch 'fp/master'

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

13 files changed, 536 insertions, 12 deletions

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 ?