IRC.

39 files changed, 1783 insertions, 214 deletions

diff --git a/community/gsoc/project_ideas/gcc_asan.mdwn b/community/gsoc/project_ideas/gcc_asan.mdwn
index 229c46ec..21a30666 100644
--- a/community/gsoc/project_ideas/gcc_asan.mdwn
+++ b/community/gsoc/project_ideas/gcc_asan.mdwn
@@ -19,3 +19,28 @@ See also the [[valgrind]] task.
 A follow-up project is porting GCC's ThreadSanitizer.
 
 Possible mentors: Thomas Schwinge (tschwinge)
+
+
+# IRC, OFTC, #gcc, 2012-12-11
+
+    <richi> hmm, is libtsan not multi-libbed?
+    <jakub> richi: it only works on x86_64 right now
+    <richi> ugh
+    <jakub> richi: so, it is multilibbed, but only built on multilibs and
+      targets which are supported
+    <jakub> richi: as it often needs lots of RAM, it is probably not going to
+      be supported on 32-bit targets at all
+    <jakub> richi: no reason not to support it on say ppc64 or sparc64 or s390x
+      I guess, just needs work
+    <richi> jakub: where is asan supported?  everywhere?
+    <jakub> richi: but then, I haven't even read what exactly libtsan does,
+      only looked at the atomics in there, and did the GCC side from what I
+      knew should be instrumented
+    <jakub> richi: asan is right now supported on x86_64/i686, ppc/ppc64,
+      perhaps partially x86 darwin (don't care) and in theory arm (nobody
+      tested)
+    <jakub> richi: porting isn't that hard, but the library isn't as clean as
+      it would be desirable portability wise
+    <jakub> richi: that said, I don't want to spend as much time as I've done
+      so far on it, and in the time I'll allocate for it optimizing the code it
+      generates is higher on the todo list than ports to other targets
diff --git a/community/gsoc/project_ideas/smp.mdwn b/community/gsoc/project_ideas/smp.mdwn
index e17c2ccf..d9788e56 100644
--- a/community/gsoc/project_ideas/smp.mdwn
+++ b/community/gsoc/project_ideas/smp.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -14,3 +14,8 @@ License|/fdl]]."]]"""]]
 # IRC, freenode, #hurd, 2012-09-30
 
     <braunr> i expect smp to be our next gsoc project
+
+
+## IRC, freenode, #hurd, 2013-01-02
+
+    <braunr> i'd like to mentor someone for adding smp to gnumach
diff --git a/continuation.mdwn b/continuation.mdwn
new file mode 100644
index 00000000..87f88f27
--- /dev/null
+++ b/continuation.mdwn
@@ -0,0 +1,18 @@
+[[!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]]."]]"""]]
+
+Continuations are a facility which allows a thread to store its state, yield
+the processor to another thread, and when it's dispatched again by the
+scheduler, it can resume with its saved state.
+
+[[!wikipedia Continuation]]
+
+See also [[GNU Mach's use of
+continuations|microkernel/mach/gnumach/continuation]].
diff --git a/glibc/signal/signal_thread.mdwn b/glibc/signal/signal_thread.mdwn
index 5341b1ab..c6e8d69e 100644
--- a/glibc/signal/signal_thread.mdwn
+++ b/glibc/signal/signal_thread.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -17,6 +17,8 @@ other threads.
 
 [[!tag open_issue_documentation]]
 
+# IRC, freenode, #hurd, 2011-04-20
+
     <braunr> bugs around signals are very tricky
     <braunr> signals are actually the most hairy part of the hurd
     <braunr> and the reason they're aynchronous is that they're handled by a
@@ -46,55 +48,5 @@ other threads.
     <braunr> sure it is
     <braunr> but does it really matter ?
     <braunr> mach and the hurd were intended to be "hyperthreaded"
-    <braunr> so basically, a thread should consume only a few kernel resources
-    <braunr> in GNU Mach, it doesn't even consume a kernel stack because only
-      continuations are used
-    <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table
-      entries, and almost no CPU time
-    <svante_> What does "hyperthreaded" mean: Do you have a reference?
-    <braunr> in this context, it just means there are a lot of threads
-    <braunr> even back in the 90s, the expected number of threads could scale
-      up to the thousand
-    <braunr> today, it isn't much impressive any more
-    <braunr> but at the time, most systems didn't have LWPs yet
-    <braunr> and a process was very expensive
-    <svante_> Looks like I have some catching up to do: What is "continuations"
-      and LWP? Maybe I also need a reference to an overview on multi-threading.
-    <ArneBab> Lightweight process?
-      http://en.wikipedia.org/wiki/Light-weight_process
-    <braunr> svante_: that's a whole computer science domain of its own
-    <braunr> yes
-    <braunr> LWPs are another names for kernel threads usually
-    <braunr> continuations are a facility which allows a thread to store its
-      state, yield the processor to another thread, and when it's dispatched
-      again by the scheduler, it can resume with its saved state
-    <braunr> most current kernels support kernel preemption though
-    <braunr> which means their state is saved based on scheduler decisions
-    <braunr> unlike continuations where the thread voluntarily saves its state
-    <braunr> if you only have continuations, you can't have kernel preemption,
-      but you end up with one kernel stack per processor
-    <braunr> while the other model allows kernel preemption and requires one
-      kernel stack per thread
-    <svante_> I know resources are limited, but it looks like kernel preemption
-      would be nice to have. Is that too much for a GSoC student?
-    <braunr> it would require a lot of changes in obscure and sensitive parts
-      of the kernel
-    <braunr> and no, kernel preemption is something we don't actually need
-    <braunr> even current debian linux kernels are built without kernel
-      preemption
-    <braunr> and considering mach has hard limitations on its physical memory
-      management, increasing the amount of memory used for kernel stacks would
-      imply less available memory for the rest of the system
-    <svante_> Are these hard limits in mach difficult to change?
-    <braunr> yes
-    <braunr> consider mach difficult to change
-    <braunr> that's actually one of the goals of my stalled project
-    <braunr> which I hope to resume by the end of the year :/
-    <svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other
-      threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread
-      sharing resources and in SunOS they are "user threads". Which is closest
-      for Hurd?
-    <braunr> i told you
-    <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually
-    <svante_> Similar to to the IBM definition then? Sorry for not remembering
-      what I've  been reading.
+
+[[open_issues/multithreading]].
diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn
index 8560fd44..3f161ba8 100644
--- a/hurd/libstore/nbd_store.mdwn
+++ b/hurd/libstore/nbd_store.mdwn
@@ -23,6 +23,17 @@ License|/fdl]]."]]"""]]
 Perhaps the protocol was extended?
 
 
+### IRC, freenode, #hurd, 2012-12-20
+
+    <youpi> if somebody has time to spend, building the nbd package makes
+      pfinet crash
+
+
+#### IRC, freenode, #hurd, 2012-12-21
+
+    <youpi> (in the testsuite)
+
+
 ## [xNBD](https://bitbucket.org/hirofuchi/xnbd/)
 
 
diff --git a/hurd/running/qemu/writeback_caching.mdwn b/hurd/running/qemu/writeback_caching.mdwn
index c9c53e3e..3b6c366b 100644
--- a/hurd/running/qemu/writeback_caching.mdwn
+++ b/hurd/running/qemu/writeback_caching.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2009, 2010, 2011, 2012
-Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 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
@@ -13,7 +13,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation]]
 
-IRC, freenode, #hurd, 2011-06-07
+
+# IRC, freenode, #hurd, 2011-06-07
 
     <braunr> hm, i guess i should have used cache=writeback with kvm before
       starting the debian installer :/
@@ -57,7 +58,8 @@ IRC, freenode, #hurd, 2011-06-07
     <braunr> well, if there is no I/O during downloading, downloading is faster
       :)
 
-IRC, freenode, #hurd, 2011-06-08
+
+# IRC, freenode, #hurd, 2011-06-08
 
     <braunr> youpi: does xen provide disk caching options ?
     <youpi> through a blktap, probably
@@ -70,7 +72,8 @@ IRC, freenode, #hurd, 2011-06-08
     <braunr> it really makes the hurd run a lot faster
     <braunr> as a workaround for emulators until I/O is reworked, ofc
 
-IRC, freenode, #hurd, 2011-06-09
+
+# IRC, freenode, #hurd, 2011-06-09
 
     <gnu_srs> braunr recommends to use writeback caching with kvm. Is this
       really recommended with the frequent crashes I experience?
@@ -88,3 +91,25 @@ IRC, freenode, #hurd, 2011-06-09
       as soon as the data is present in the host page cache.  This is safe as
       long as you trust your host.  If your host crashes or loses power, then
       the guest may experience data corruption." (from the qemu manpage)
+
+
+# IRC, freenode, #hurd, 2012-12-30
+
+    <gg0> http://bugs.debian.org/622319#51
+    <gg0> braunr: just pointing out writeback is default since qemu 1.3.0
+    <gg0> that makes hurd VMs faster by default :p
+    <braunr> ahh :)
+    <gg0> about data loss I had read (qemu man pages?) it may occur in case of
+      loss of power
+    <braunr> well yes
+    <gg0> probably on hurd may occur even with writethrough due to non
+      journaled ext2
+    <braunr> yes but the hurd flushes everything (and i mean everything) every
+      5 seconds
+    <gg0> http://lists.gnu.org/archive/html/qemu-devel/2012-02/msg02682.html
+    <braunr> so it's actually less likely to lose data because of the hurd than
+      because of power loss
+    <braunr> what i meant earlier is that we've never experienced unexpected
+      data loss because of qemu writeback policy
+    <braunr> if data is in the host cache and you lose power, qemu or not, you
+      lose data
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index d30cc850..edd31017 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -70,3 +70,27 @@ Amongst other things, support for [[IOCTL]]s is missing.
     <braunr> ok
     <braunr> i'd like to set this up on my VMs but it looks bugged :/
     <braunr> i can't manage to set correctly set the gateway
+
+
+### IRC, freenode, #hurd, 2012-12-12
+
+    <braunr> hm, pfinet seems not to support ipv6 well at all :(
+    <pinotree> braunr: really?
+    <braunr> pinotree: i can't manage to set a global address statically and
+      make it communicate with neighbours
+    <braunr> pfinet receives the advertisement (during neighbour discovery) but
+      immediately resends the same solicitation again
+    <gnu_srs> According to the pfinet/README IPv6 support was added in 2007
+      from Linux 2.2.14 while the rest is from 2.2.12
+    <braunr> according to me, bugs were added at the same time
+    <braunr> :p
+    <braunr> in addition, ipv6 in linux 2.2 was, uh, not working well either
+    <braunr> even with 2.4, it was still messy
+    <gnu_srs> maybe we should try to upgrade the TCP/IP stack to something
+      2.6+?
+    <gnu_srs> (a lot of work though)
+    <braunr> we've already had that discussion
+    <gnu_srs> Yes. What is the best way forward, a GSoC task? 
+    <gnu_srs> There is one already:
+      http://www.gnu.org/software/hurd/community/gsoc/project_ideas/tcp_ip_stack.html
+    <braunr> personally, i'd advocate resuing code from netbsd
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index e1f6debc..9ba67219 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -520,3 +520,11 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
 
     <braunr> for those interested, x15 is now a project of its own, with no
       gnumach compability goal, and covered by gplv3+
+
+
+### IRC, freenode, #hurd, 2012-12-31
+
+    <braunr> bits of news about x15: it can now create tasks, threads, vm_maps,
+      physical maps (cpu-specific page tables) for user tasks, and stack
+      tracing (in addition to symbol resolution when symbols are available)
+      were recently added
diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn
index edd0cfdb..894adc76 100644
--- a/microkernel/mach/gnumach.mdwn
+++ b/microkernel/mach/gnumach.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2011 Free Software
+[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2011, 2013 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -79,6 +79,8 @@ GNU/Hurd.
   * [[Debugging]]
   * [[Boot_Trace]]
   * [[Memory_Management]]
+  * [[Continuation]]s
+  * [[Preemption]]
   * [[Projects]]
       * [[Rules]]
       * [[Open Issues|tag/open_issue_gnumach]]
diff --git a/microkernel/mach/continuation.mdwn b/microkernel/mach/gnumach/continuation.mdwn
index 7a3267f3..cdd942b7 100644
--- a/microkernel/mach/continuation.mdwn
+++ b/microkernel/mach/gnumach/continuation.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -8,7 +9,9 @@ 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]]."]]"""]]
 
-[[Mach]] internally uses *continuation*s for kernel [[thread]] management.
+[[!tag open_issue_gnumach]]
+
+[[Mach]] internally uses *[[/continuation]]*s for kernel [[thread]] management.
 
 The advantage is that not a full kernel thread stack has to be preserved in
 case that a thread is about to enter a blocking state.  This saves space.  It
@@ -16,9 +19,8 @@ is not clear this is still worthwhile given today's RAM offerings.  (How many
 kernel threads are there, typically?)
 
 And, this would no longer be possible in case Mach were be made a
-[[preemptive|preemtion]] kernel.  In the latter case, the kernel itself, that
+[[preemptive|preemption]] kernel.  In the latter case, the kernel itself, that
 is, kernel threads can be preempted, and then their full state needs to be
 preserved.
 
-[[!tag open_issue_documentation]] <!-- Not linked to from any Mach page.  Move
-to GNU Mach pages, as this is only an implementation detail?  -->
+See also [[open_issues/multithreading]].
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 874f5f07..3a4f560c 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 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
@@ -91,6 +91,11 @@ Configuration](http://www.gnu.org/software/hurd/gnumach-doc/Configuration.html)
 contains a list of device drivers that are included in GNU Mach and elaborates
 on the hardware devices they support.
 
+## DDE
+
+[[hurd/DDE]] provides more up-to-date network device drivers, based on Linux
+2.6.29 code, running as user-space processes.
+
 # User Success Reports
 
 These boards are known to work. Gnumach/Hurd has been installed and run on these board successfully. 
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 3e158b7c..a1d9a99d 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -133,3 +133,47 @@ License|/fdl]]."]]"""]]
     <braunr> using sysenter/sysexit makes it even faster
 
 [[open_issues/system_call_mechanism]].
+
+
+# IRC, freenode, #hurd, 2012-12-12
+
+    <braunr> youpi: is the 2g split patch really needed ?
+    <braunr> or rather, is it really a good thing for most people ?
+    <braunr> instead of the common 3g/1g
+    <braunr> it reduces tasks' address space but allows the kernel to reference
+      more physical memory
+    <braunr> the thing is, because of the current page cache implementation,
+      most of the time, this physical memory remains unused, or very rarely
+    <youpi> ?
+    <braunr> on the other hand, a larger address space for tasks allows running
+      more threads (more space for tasks) and not failing while linking webkit
+      .. :)
+    <youpi> it's needed for quite a few compilations, yes
+    <braunr> if you refer to the link stage, with a decent amount of swap, it
+      goes without trouble
+    <youpi> well, if your kernel doesn't have 2GiB physical addressing
+      capacity, userspace won't have >2GiB memory capacity either
+    <youpi> does it now?
+    <youpi> it didn't use to
+    <youpi> and it was crawling like hell for some builds
+    <youpi> (until simply hanging)
+    <braunr> i never have a problem e.g. runing the big malloc glibc test
+    <braunr> (bug22 or something like that)
+    <youpi> that doesn't involve objects from the fs, does it?
+    <braunr> no
+    <braunr> as long as it's anonymous memory, it's ok
+    <braunr> the default pager looks safe, i'm pretty sure our lockups are
+      because of something in ext2fs
+    <youpi> braunr: well, an alternative would be to build two kernels, one 2/2
+      and one 3/1
+    <braunr> not really worth it
+    <braunr> i was just wondering
+    <braunr> i usually prefer a 3/1 on darnassus, but i don't build as often as
+      a buildd :x
+    <youpi> or we can go with 2.5/1.5
+    <youpi> I can do that on bach & mozart for instance
+    <youpi> (they have their own kernel anyway)
+    <braunr> youpi: if you think it's worth the effort
+    <braunr> again, i was just wondering out loud
+    <youpi> braunr: well, bach & mozart don't have > 1.2GiB mem anyway
+    <youpi> so it doesn't pose problem
diff --git a/microkernel/mach/gnumach/preemption.mdwn b/microkernel/mach/gnumach/preemption.mdwn
new file mode 100644
index 00000000..520f7bc9
--- /dev/null
+++ b/microkernel/mach/gnumach/preemption.mdwn
@@ -0,0 +1,20 @@
+[[!meta copyright="Copyright © 2010, 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
+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]]
+
+There currently is no kernel preemption in GNU Mach.
+
+If GNU Mach were made a a preemptive kernel, using [[continuation]]s would
+probably no longer make sense as the kernel itself, that is, kernel threads can
+be preempted, and then their full state needs to be preserved.
+
+See also [[open_issues/multithreading]].
diff --git a/microkernel/mach/message/msgh_id.mdwn b/microkernel/mach/message/msgh_id.mdwn
index 986fcbc7..a7157a37 100644
--- a/microkernel/mach/message/msgh_id.mdwn
+++ b/microkernel/mach/message/msgh_id.mdwn
@@ -252,3 +252,8 @@ files.
       that adds a gnumach.defs interface
     <braunr> tschwinge: if you think it's ok, i'll rewrite a formal changelog
       so it can be applied
+
+
+## IRC, freenode, #hurd, 2012-09-30
+
+    <braunr> youpi: hey, didn't see you merged the page cache stats branch :)
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
index 2d273ba1..66da44b9 100644
--- a/open_issues/64-bit_port.mdwn
+++ b/open_issues/64-bit_port.mdwn
@@ -57,3 +57,83 @@ the [[microkernel/mach/gnumach/ports/Xen]] platform.
       and switching to long mode, then jumping to c code to complete the
       initialization
     <braunr> i think i'll go the second way with x15, so you'll have the two :)
+
+
+# IRC, freenode, #hurd, 2012-12-12
+
+In context of [[microkernel/mach/gnumach/memory_management]].
+
+    <tschwinge> Or with a 64-bit one?  ;-P
+    <braunr> tschwinge: i think we all had that idea in mind :)
+    <pinotree> tschwinge: patches welcome :P
+    <youpi> tschwinge: sure, please help us settle down with the mig stuff
+    <youpi> what was blocking me was just deciding how to do it
+    <braunr> hum, what's blocking x86_64, except time to work on it ?
+    <youpi> deciding the mig types & such things
+    <youpi> i.e. the RPC ABI
+    <braunr> ok
+    <braunr> easy answer: keep it the same
+    <youpi> sorry, let me rephrase
+    <youpi> decide what ABI is supposed to be on a 64bit system, so as to know
+      which way to rewrite the types of the kernel MIG part to support 64/32
+      conversion
+    <braunr> can't this be done in two steps ?
+    <youpi> well, it'd mean revamping the whole kernel twice
+    <youpi> as the types at stake are referenced in the whole RPC code
+    <braunr> the first step i imagine would simply imply having an x86_64
+      kernel for 32-bits userspace, without any type change (unless restricting
+      to 32-bits when a type is automatically enlarged on 64-bits)
+    <youpi> it's not so simple
+    <youpi> the RPC code is tricky
+    <youpi> and there are alignments things that RPC code uses
+    <youpi> which become different when build with a 64bit compiler
+    <pinotree> there are also things like int[N] for io_stat_struct and so on
+    <braunr> i see
+    <youpi> making the code wrong for 32
+    <youpi> thus having to change the types
+    <youpi> pinotree: yes
+    <pinotree> (doesn't mig support structs, or it is too clumsy to be used in
+      practice?)
+    <braunr> pinotree: what's the problem with that (i explcitely said changing
+      int to e.g. int32_t)
+    <youpi> that won't fly for some of the calls
+    <youpi> e.g. getting a thread state
+    <braunr> pinotree: no it doesn't support struct
+    <pinotree> braunr: that some types in struct stat are long, for instance
+    <braunr> pinotree: same thing with longs
+    <braunr> youpi: why wouldn't it ?
+    <youpi> that wouldn't work on a 64bit system
+    <youpi> so we can't make it int32_t in the interface definition
+    <braunr> i understand the alignment issues and that the mig code adjusts
+      the generated code, but not the content of what is transfered
+    <braunr> well of course
+    <braunr> i'm talking about the first step here
+    <braunr> which targets a 32-bits userspace only
+    <youpi> ok, so we agree
+    <youpi> the second step would have to revamp the whole RPC code again
+    <braunr> i imagine the first to be less costly
+    <braunr> well, actually no
+    <braunr> you're right, the mig stuff would be easy on the application side,
+      but more complicated on the kernel side, since it would really mean
+      dealing with 64-bits values there
+    <braunr> (unless we keep a 3/1 split instead of giving the full 4g to
+      applications)
+
+See also [[microkernel/mach/gnumach/memory_management]].
+
+    <youpi> (I don't see what that changes)
+    <braunr> if the kernel still runs with 32-bits addresses, everything it
+      recevies from or sends through mig can be stored with the user side
+      32-bits types
+    <youpi> err, ok, but what's the point of the 64bit kernel then ? :)
+    <braunr> and it simply uses 64-bits addresses to deal with physical memory
+    <youpi> ok
+    <youpi> that could even be a 3.5/0.5 split then
+    <braunr> but the memory model forces us to run either at the low 2g or the
+      highest ones
+    <youpi> but linux has 3/1, so we don't need that
+    <braunr> otherwise we need an mcmodel=medium
+    <braunr> we could do with mcmodel=medium though, for a time
+    <braunr> hm actually no, it would require mcmodel=large
+    <braunr> hum, that's stupid, we can make the kernel run at -2g, and use 3g
+      up to the sign extension hole for the kernel map
diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn
index 3255683c..34428586 100644
--- a/open_issues/alarm_setitimer.mdwn
+++ b/open_issues/alarm_setitimer.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -29,3 +29,159 @@ for a signal, while on GNU/Hurd it gets a new alarm and exits.
     <braunr> it seems doesn't seem to leave a timer disarmed when the interval
       is set to 0
     <braunr> (which means a one shot timer is actually periodic ..)
+
+
+## IRC, freenode, #hurd, 2012-12-26
+
+    <braunr> youpi: tschwinge: the setitimer issue
+      http://www.gnu.org/software/hurd/open_issues/alarm_setitimer.html) is
+      because of the global preemptor installed by setitimer not being run when
+      sigalrm is catched
+    <braunr> if anyone has a good definition for a preemptor, let us know (mine
+      is currently "something that is scanned on signal delivery and can alter
+      this delivery")
+    <youpi> I don't have any better definition
+    <pinotree> braunr: ah, that explains indeed
+    <pinotree> thanks
+    <braunr> i think i found the problem :)
+    <braunr> seems to be a minor overlook from drepper
+    <braunr> (or the real author if he was only the committer)
+    <braunr> hurd_preempt_signals augments _hurdsig_preempted_set with the
+      signals from the installed preemptor
+    <braunr> but the inline version in setitimer doesn't
+    <braunr> and post_signal actually checks that
+    <braunr> the preemptor itself looks wrong, since its sigcode range is 0, 0
+      whereas SI_TIMER is used when raising SIGALRM ...
+    <braunr> ah but that's a recent change, right
+    <braunr> it came with "implement SA_SIGINFO signal handlers"
+      (e19a2fad70b187e5efe79768f86a1f05cb5e0390, Tue Feb 21 02:41:18 2012)
+    <braunr> yes, fixed :)
+    <braunr> patch committed at
+      http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/setitimer_fix
+    <youpi> and pushed to the debian package
+
+
+## IRC, freenode, #hurd, 2012-12-27
+
+    <braunr> do we know any application that was broken because of setitimer ?
+    <pinotree> braunr: bits in the python and perl test suites
+    <braunr> ok
+
+
+## IRC, freenode, #hurd, 2012-12-28
+
+    <pinotree> braunr: ah, also libglib-perl's testsuite is affected by the
+      alarm/setitimer issue
+    <braunr> pinotree: only tests ? :(
+    <pinotree> braunr: yeah
+    <braunr> ok, we don't win that much on this fix, but anyway, still good to
+      have
+    <pinotree> but that source is pretty quick to compile and check
+    <pinotree> braunr: eh, so far that's what i found myself
+
+
+## IRC, freenode, #hurd, 2013-01-04
+
+See also [[select]].
+
+    <youpi> bummer, we have broken ghc completely with the latest glibc patches
+    <pinotree> youpi: what do you mean?
+    <youpi> pinotree: it just hangs on installation
+    <youpi> pinotree: it seems ghc was disturbed by the setitimer patch
+    <youpi> pinotree: http://paste.debian.net/221807/
+    <youpi> pinotree: it seems to be simply due to nested locking of
+      _hurd_siglock :/
+    <youpi> pinotree: I wonder whether this code has ever been really tested
+    <youpi> oops
+    <youpi> braunr: my comments above were for you actually :)
+    <youpi> braunr: see the update I've just commited to the debian patch
+    <youpi> I've added a parameter to setitimer_locked, to know whether the
+      lock is already taken or not
+    <youpi> that does fix ghc
+    <youpi> as well as the gdb ntpdate hang, apparently
+    <youpi> I can confirm that the single-select patch breaks ntpdate for some
+      reason
+    <youpi> I wonder whether it could be due to port set behavior being
+      different from single reply port
+    <youpi> I believe I understand what happens
+    <youpi> it's a know issue in select
+    <youpi> it's not interruptible by a SIGALRM for instance
+    <youpi> which is what ntpdate uses
+    <youpi> when __io_select is used, it *is* interruptible
+    <youpi> but when __mach_msg is used, it is *not* interruptible
+    <youpi> it happens that by luck, ntpdate uses just one fd, and thus it's
+      __io_select which is used, and thus it gets an interruption after 1s
+      (instead of after 60s, the timeout)
+    <youpi> with braunr's patch, it's __mach_msg which is used to wait, and
+      thus the interruption doesn't happen, and we have to wait  60s, the
+      timeout...
+    <youpi> so braunr's patch is still correct, it's the __mach_msg call which
+      we do need to make interruptible (it was already on the todolist)
+    <youpi> I'll rebuild ntpdate with a 1s timeout
+    <youpi> that'll at least fix that
+    <youpi> rah, no, doesn't work, it insists on getting its alarm
+    <youpi> Mmm, no, the __mach_msg call doesn't even return
+    <youpi> even though MACH_RCV_TIMEOUT is set, and to is 1000
+    <braunr> youpi: i see
+    <braunr> gnu_srs: and you, see how youpi analysed and understood the
+      problem, instead of just guessing :p
+    <braunr> youpi: it doesn't return ?
+    <braunr> iirc, the __mach_msg wrapper deals with the interruptible flag
+    <youpi> braunr: yes, __mach_msg deals with the interruptible flag by
+      looping !
+    <youpi> and the info page says it: if it's interrupted too often, it may
+      just never return
+    <youpi> that's what actually happens here
+    <youpi> (ntpdate sets an itimer more often than every 1s)
+    <braunr> youpi: ew :)
+    <youpi> I'll test a bit more, and submit a patch
+    <pinotree> youpi: otoh a _locker function usually means it expects a locked
+      mutex ;)
+    <pinotree> i also i wondered whether there could be a race in the settimer
+      mini-thread, between its mach_msg and its reading of the interval
+    <youpi> pinotree: right, we could as well just lock anyway
+    <youpi> there could be indeed
+    <pinotree> youpi: i don't know much about the internals of signal
+      dispatching, but could it happen the following:
+    <pinotree> in timer thread, mach_msg expires → sig_post_request → before
+      the main thread receives/processes the signal, the timer thread iterates
+      again on its while(1), using the same interval previously used
+    <pinotree> ?
+    <youpi> did you check the comment above __msg_sig_post_request?
+    <pinotree> ah ok
+    <youpi> I'm not sure how that works, but it's supposed to :)
+    <pinotree> just wonder: wouldn't it be simplier if the logic to change the
+      timeout would be in the timer thread, instead of relying on the main
+      thread adjusting it?
+    <youpi> maybe there are some semantic details that wouldn't be right with
+      such approach
+    <pinotree> i see
+    <pinotree> i guess so if the new interval is 0, the thread can be properly
+      suspened (or killed, if the former fails)
+    <youpi> could be something like this, yes
+    <pinotree> youpi: ah, wrt your comments of tonight: at least with the
+      current setitimer patch (in -38), a simple alarm() test app works, and i
+      saw few python tests can be reenabled now
+    <youpi> ok
+    <pinotree> so even if not totally correct, at least it had some positive
+      effects
+    <pinotree> youpi: wrt the double lock issue of _hurd_siglock, what about
+      using the "crit" parameter of setitimer_locked?
+    <youpi> it may have various values
+    <youpi> depending whether we're already in the critical section etc.
+    <pinotree> restart_itimer does not take that lock, so we could check
+      whether crit is null, and in that case not even bothering to check the
+      signal preemptors, since it was called as a result of own setitimer
+      thread?
+    <youpi> I'd rather avoid binding whether the mutex is held to whether the
+      call is coming from the actual premptor
+    <youpi> again, crit may be null if we're already in the critical section
+      when setitimer is called
+    <braunr> setitimer already does unclean things with preemptors
+    <youpi> not a good thing to add more :)
+    <pinotree> fair enough, so a simple bool should do the job
+    <braunr> i mean, the whole thing is "cheezoid" :)
+    <braunr> it probably needs a rewrite some day
+    <braunr> so "in the meantime" (of years, i know)
+    <pinotree> braunr: and temporary, too
+    <braunr> but a bool is fine too, sure :)
diff --git a/open_issues/arm_port.mdwn b/open_issues/arm_port.mdwn
index 2d8b9038..65a82d92 100644
--- a/open_issues/arm_port.mdwn
+++ b/open_issues/arm_port.mdwn
@@ -12,7 +12,31 @@ Several people have expressed interested in a port of GNU/Hurd for the ARM
 architecture.
 
 
-# IRC, freenode, #hurd, 2012-10-09
+# IRC, freenode, #hurd, 2012-07-28
+
+    <mcsim> Has anyone heard about porting hurd and gnu/mach to arm
+      architecture?
+    <braunr> mcsim: i think so
+    <braunr> mcsim: why are you asking ?
+    <mcsim> I found an article where author stated that he has ported hurd to
+      arm, but I have never met this information before.
+    <mcsim> He wrote ethernet driver and managed to use ping command
+    <mcsim> author's name is Sartakov Vasily
+    <braunr> well that's possible, a long time ago
+    <braunr> and it was probably not complete enough to be merged upstream
+    <braunr> like many other attempts at many other things
+    <mcsim> Not so long. Article is dated by June 2011.
+    <braunr> do you have a link ?
+    <mcsim> Yes, but it is in Russian.
+    <braunr> oh
+    <braunr> well i don't remember him sharing that with us
+    <antrik> mcsim: he did some work on porting Mach, but AIUI never got it
+      nearly finished
+    <antrik> nowadays he does L4 stuff
+    <antrik> was also at FOSDEM
+
+
+## IRC, freenode, #hurd, 2012-10-09
 
     <mcsim> bootinfdsds: There was an unfinished port to arm, if you're
       interested.
diff --git a/open_issues/fcntl_F_SETFL_FD.mdwn b/open_issues/fcntl_F_SETFL_FD.mdwn
new file mode 100644
index 00000000..4d270250
--- /dev/null
+++ b/open_issues/fcntl_F_SETFL_FD.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="fcntl.*F_SETFL.*FD_.*"]]
+
+[[!tag open_issue_porting]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-12-16
+
+    <pinotree> http://lists.debian.org/<50CE505F.3040106@pyro.eu.org>
+    <pinotree> or http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=679198#123
+      too
+    <youpi> ouch, there are quite a few!
+    <pinotree> most are "duplicated", like the source in webkit2 copies (so
+      fixing it once upstream will make it fixed progressively once the copies
+      are upgraded)
+    <youpi> ah, ok
+    <pinotree> similar for ruby 1.8/1.9/jruby
diff --git a/open_issues/gdb_attach.mdwn b/open_issues/gdb_attach.mdwn
index 4e4f2ea0..8f1b7b48 100644
--- a/open_issues/gdb_attach.mdwn
+++ b/open_issues/gdb_attach.mdwn
@@ -39,3 +39,18 @@ License|/fdl]]."]]"""]]
     <braunr> pinotree: it uses setjmp
     <braunr> hm random corruptions :/
     <braunr> definitely looks like a concurrency problem
+
+
+# IRC, freenode, #hurd, 2012-05-23
+
+    <pinotree>
+      /build/buildd-gdb_7.4really-1-hurd-i386-UKStgK/gdb-7.4really/gdb/thread.c:72:
+      internal-error: inferior_thread: Assertion `tp' failed.
+    <pinotree> arg
+    <tschwinge> pinotree: Been doing anything "special"?   Is it reproducible? 
+    <pinotree> trying to debug something
+    <tschwinge> Indeed.  ;-)
+    <pinotree> i'm not sure i'm doing anything special, just trying to attach a
+      process
+    <tschwinge> That is supposed to work.
+    <tschwinge> If the permission match.
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index e2b968c9..2751c377 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -1196,9 +1196,6 @@ There is quite a baseline of failures.
 
   * `tst-array*`
 
-    Failures also seen on GNU/Linux; [[!message-id
-    "50950082.1070906@df1tl.local.here"]].
-
         gcc-4.6 tst-array1.c -c -std=gnu99 -fgnu89-inline  -O2 -Wall -Winline -Wwrite-strings -fmerge-all-constants -frounding-math -g -Wno-parentheses -Wstrict-prototypes         -I../include -I[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/
         gcc-4.6 -nostdlib -nostartfiles -o [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/tst-array1  -Wl,-dynamic-linker=/lib/ld.so.1   -Wl,-z,combreloc -Wl,-z,relro -Wl,--hash-style=both [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486
         [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf/ld.so.1 --library-path [...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/math:[...]/tschwinge/Roger_Whittaker.build-gcc-4.6-486/elf:[
@@ -1232,6 +1229,18 @@ There is quite a baseline of failures.
 
     `tst-array5-static` passes.
 
+    IRC, freenode, #glibc, 2012-11-01:
+
+        <jsm28> tschwinge: I saw the array tests fail, built a new binutils and
+          a new compiler configured with new binutils and the failures went
+          away.
+        <jsm28> So they may depend on having new-enough GCC configured with
+          new-enough binutils, or something like that.
+        <tuliom> jsm28: Did you use gcc 4.7 or trunk?
+        <jsm28> tuliom: 4.7.
+
+    [[!message-id "50950082.1070906@df1tl.local.here"]].
+
   * `tst-audit1.out`, `tst-audit2.out`
 
     SIGKILL.
diff --git a/open_issues/glibc/0.4.mdwn b/open_issues/glibc/0.4.mdwn
new file mode 100644
index 00000000..a8892876
--- /dev/null
+++ b/open_issues/glibc/0.4.mdwn
@@ -0,0 +1,28 @@
+[[!meta copyright="Copyright © 2012 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 open_issue_libpthread]]
+
+
+# IRC, freenode, #hurd, 2012-12-14
+
+In context of [[packaging_libpthread]]/[[libpthread]].
+
+    <pinotree> once libc is switched internally from cthreads to pthreads (thus
+      breaking its BC), may be worth cleanup the hurd-specific exported symbols
+    <tschwinge> pinotree: Yes.  If you already have ideas about what to clean
+      up, feel free to add a new page or a section on open_issues/glibc.
+    <pochu> we're gonna break backwards compatibility in glibc on hurd? that
+      could be the perfect moment to fix the /dev/fd/N problem without adding
+      new RPCs, though we'd probably have to break backwards-compatibility in
+      the exec server IIRC...
+    <tschwinge> pochu: Oh, I have to re-read that discussion, but thanks for
+      reminding!
+    <tschwinge> pochu: Won't happen today or tomorrow, but "sometime".
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index e5e9d2c5..46454207 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -1026,6 +1027,9 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     < braunr> cache for kernel map entries in vm_map ?
     < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as
       there is no kernel preemption
+
+[[microkernel/mach/gnumach/preemption]].
+
     < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL
       times a second.
     < braunr> "
@@ -2182,3 +2186,44 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> also, i wrote the implementation in userspace, without
       functionality pmap provides (although i could have emulated it
       afterwards)
+
+
+# IRC, freenode, #hurd, 2013-01-06
+
+    <youpi> braunr: panic: vm_map: kentry memory exhausted
+    <braunr> youpi: ouch
+    <youpi> that's what I usually get
+    <braunr> ok
+    <braunr> the kentry area is a preallocated memory area that is used to back
+      the vm_map_kentry cache
+    <braunr> objects from this cache are used to describe kernel virtual memory
+    <braunr> so in this case, i simply assume the kentry area must be enlarged
+    <braunr> (currently, both virtual and physical memory is preallocated, an
+      improvement could be what is now done in x15, to preallocate virtual
+      memory only
+    <braunr> )
+    <youpi> Mmm, why do we actually have this limit?
+    <braunr> the kentry area must be described by one entry
+    <youpi> ah, sorry, vm/vm_resident.c:       kentry_data =
+      pmap_steal_memory(kentry_data_size);
+    <braunr> a statically allocated one
+    <youpi> I had missed that one
+    <braunr> previously, the zone allocator would do that
+    <braunr> the kentry area is required to avoid recursion when allocating
+      memory
+    <braunr> another solution would be a custom allocator in vm_map, but i
+      wanted to use a common cache for those objects too
+    <braunr> youpi: you could simply try doubling KENTRY_DATA_SIZE
+    <youpi> already doing that
+    <braunr> we might even consider a much larger size until it's reworked
+    <youpi> well, it's rare enough on buildds already
+    <youpi> doubling should be enough
+    <youpi> or else we have leaks
+    <braunr> right
+    <braunr> it may not be leaks though
+    <braunr> it may be poor map entry merging
+    <braunr> i'd expected the kernel map entries to be easier to merge, but it
+      may simply not be the case
+    <braunr> (i mean, when i made my tests, it looked like there were few
+      kernel map entries, but i may have missed corner cases that could cause
+      more of them to be needed)
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn
index d128c668..22b05953 100644
--- a/open_issues/gnumach_page_cache_policy.mdwn
+++ b/open_issues/gnumach_page_cache_policy.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -282,6 +282,9 @@ License|/fdl]]."]]"""]]
       dropped again...
     <braunr> what seems very weird though is that we're normally using
       continuations
+
+[[microkernel/mach/gnumach/continuation]].
+
     <antrik> braunr: you mean in the kernel? how is that relevant to the topic
       at hand?...
     <braunr> antrik: continuations have been designed to reduce the number of
diff --git a/open_issues/gnumach_tick.mdwn b/open_issues/gnumach_tick.mdwn
index eed447f6..f29df6de 100644
--- a/open_issues/gnumach_tick.mdwn
+++ b/open_issues/gnumach_tick.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -17,6 +17,9 @@ License|/fdl]]."]]"""]]
       it is true?
     <braunr> yes
     <braunr> and it's not preemptible
+
+[[microkernel/mach/gnumach/preemption]].
+
     <pinotree> braunr: that means a gnumach kernel currently has a maximum
       uptime of almost 500 days
     <braunr> pinotree: what do you mean ?
diff --git a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
index 57eb403d..80fe36f8 100644
--- a/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
+++ b/open_issues/libmachuser_libhurduser_rpc_stubs.mdwn
@@ -113,3 +113,11 @@ License|/fdl]]."]]"""]]
       out?
     <tschwinge> pinotree: That discussion has not yet come to a conclusion, I
       think.  (I'd say: yes.)
+
+
+# IRC, freenode, #hurd, 2012-12-17
+
+    <pinotree> what was the idea about using the rpc stubs currently in
+      libmachuser and libhurduser? should they be linked to explicitly, or
+      assume libc brings them?
+    <braunr> pinotree: libc should bring them
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index befc1378..05aab85f 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -1257,6 +1257,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
     <braunr> i'll add traces to know which step causes the error
 
 
+### IRC, freenode, #hurd, 2012-12-11
+
+    <youpi> braunr: mktoolnix seems like a reproducer for the libports thread
+      priority issue
+    <youpi> (3 times)
+    <braunr> youpi: thanks
+    <braunr> youpi: where is that tool packaged ?
+    <pinotree> he probably means the mkvtoolnix source
+    <braunr> seems so
+    <braunr> i don't find anything else
+    <youpi> that's it, yes
+
+
 ## IRC, freenode, #hurd, 2012-12-05
 
     <braunr> tschwinge: i'm currently working on a few easy bugs and i have
@@ -1326,3 +1339,123 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
     <braunr> i wondered for a long time why the load average was so high on the
       hurd under even "light" loads
     <braunr> now i know :)
+
+
+## IRC, freenode, #hurd, 2012-12-27
+
+    <youpi> btw, good news: the installer works with libpthread
+    <youpi> (well, at least boots, I haven't tested the  installation)
+    <braunr> i can do that if the image is available publically
+    <braunr> youpi: the one thing i suspect won't work right is the hurd
+      console :/
+    <braunr> so we might need to not enable it by default
+    <youpi> braunr: you mean the mode setting?
+    <braunr> youpi: i don't know what's wrong with the hurd console, but it
+      seems to deadlock with pthreads
+    <youpi> ah?
+    <youpi> I don't have such issue
+    <braunr> ah ? i need to retest that then
+
+Same issue as [[term_blocking]] perhaps?
+
+
+## IRC, freenode, #hurd, 2013-01-06
+
+    <youpi> it seems fakeroot has become slow as hell
+    <braunr> fakeroot is the main source of dead name notifications
+    <braunr> well, a very heavy one
+    <braunr> with pthreads hurd servers, their priority is raised, precisely to
+      give them time to handle those dead name notifications
+    <braunr> which slows everything else down, but strongly reduces the rate at
+      which additional threads are created to handle dn notifications
+    <braunr> so this is expected
+    <youpi> ok :/
+    <braunr> which is why i mentioned a rewrite of io_select into a completely
+      synchronous io_poll
+    <braunr> so that the client themselves remove their requests, instead of
+      the servers doing it asynchronously when notified
+    <youpi> by "slows everything else down", you mean, if the servers do take
+      cpu time?
+    <braunr> but considering the amount of messaging it requires, it will be
+      slow on moderate to large fd sets with frequent calls (non blocking or
+      low timeout)
+    <braunr> yes
+    <youpi> well here the problem is not really it gets slowed down
+    <youpi> but that e.g. for gtk+2.0 build, it took 5h cpu time
+    <youpi> (and counting)
+    <braunr> ah, the hurd with pthreads is noticeably slower too
+    <braunr> i'm not sure why, but i suspect the amount of internal function
+      calls could account for some of the overhead
+    <youpi> I mean the fakeroot process
+    <youpi> not the server process
+    <braunr> hum
+    <braunr> that's not normal :)
+    <youpi> that's what I meant
+    <braunr> well, i should try to build gtk+20 some day
+    <braunr> i've been building glibc today and it's going fine for now
+    <youpi> it's the install stage which poses problem
+    <youpi> I've noticed it with the hurd package too
+    <braunr> the hurd is easier to build
+    <braunr> that's a good test case
+    <braunr> there are many times when fakeroot just doesn't use cpu, and it
+      doesn't look like a select timeout issue (it still behaved that way with
+      my fixed branch)
+    <youpi> in general, pfinet is taking really a lot of cpu time
+    <youpi> that's surprising
+    <braunr> why ?
+    <braunr> fakeroot uses it a lot
+    <youpi> I know
+    <youpi> but still
+    <youpi> 40% cpu time is not normal
+    <youpi> I don't see why it would need so much cpu time
+    <braunr> 17:57 < braunr> but considering the amount of messaging it
+      requires, it will be slow on moderate to large fd sets with frequent
+      calls (non blocking or low timeout)
+    <youpi> by "it", what did you mean?
+    <youpi> I thought you meant the synchronous select implementation
+    <braunr> something irrelevant here
+    <braunr> yes
+    <braunr> what matters here is the second part of my sentence, which is what
+      i think happens now
+    <youpi> you mean it's the IPC overhead which is taking so much time?
+    <braunr> i mean, it doesn't matter if io_select synchronously removes
+      requests, or does it by destroying ports and relying on notifications,
+      there are lots of messages in this case anyway
+    <braunr> yes
+    <youpi> why "a lot" ?
+    <youpi> more than one per select call?
+    <braunr> yes
+    <youpi> why ?
+    <braunr> one per fd
+    <braunr> then one to wait
+    <youpi> there are two in faked
+    <braunr> hum :)
+    <braunr> i remember the timeout is low
+    <braunr> but i don't remember its value
+    <youpi> the timeout is NULL in faked
+    <braunr> the client then
+    <youpi> the client doesn't use select
+    <braunr> i must be confused
+    <braunr> i thought it did through the fakeroot library
+    <braunr> but yes, i see the same behaviour, 30 times more cpu for pfinet
+      than faked-tcp
+    <braunr> or let's say between 10 to 30
+    <braunr> and during my tests, these were the moments the kernel would
+      create lots of threads in servers and fail because of lack of memory,
+      either kernel memory, or virtual in the client space (filled with thread
+      stacks)
+    <braunr> it could be due to threads spinning too much
+    <braunr> (inside pfinet)
+    <youpi> attaching a gdb shows it mostly inside __pthread_block
+    <youpi> uh, how awful pfinet's select is
+    <youpi> a big global lock
+    <youpi> whenever something happens all threads get woken up
+    <pinotree> BKL!
+    * pinotree runs
+    <braunr> we have many big hurd locks :p
+    <youpi> it's rather a big translator lock
+    <braunr> more than a global lock it seems, a global condvar too, isn't it ?
+    <youpi> sure
+    <braunr> we have a similar problem with the hurd-specific cancellation
+      code, it's in my todo list with io_select
+    <youpi> ah, no, the condvar is not global
diff --git a/open_issues/locking_issues.mdwn b/open_issues/locking_issues.mdwn
index e15562bc..8008e5a1 100644
--- a/open_issues/locking_issues.mdwn
+++ b/open_issues/locking_issues.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 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
@@ -32,3 +32,16 @@ the behavior of the locking logic.  There are tools for formal
 verification/[[code_analysis]] that can likely help here.
 
 There is a [[!FF_project 278]][[!tag bounty]] on this task.
+
+
+# IRC, fOFTC, #debian-hurd, 2012-12-15
+
+    <Steap> youpi: can you think of a locking error recently fixed in the
+      translators ? I'd like to try a Coccinelle script on a real-world example
+    <youpi> 0b6286a3c5eb86e3cca72d0840fc009855e4fba5 for instance
+    <youpi> or a60414ee7fdabb2bdfb17fe82b9a09f811bd2de0
+    <youpi> or b8082aab5049f753abd720a5ef6a113e2acef911
+    <Steap> thx, I think I might have caught a few double unlocks, I'll send
+      patches/bug reports this week-end
+    <youpi> oh, good :)
+    <tschwinge> Steap: Great -- looking forward to that!
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index f42601b4..f631a80b 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -11,7 +11,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_hurd]]
 
-Hurd servers / VFS libraries are multithreaded.
+Hurd servers / VFS libraries are multithreaded.  They can even be said to be
+"hyperthreaded".
 
 
 # Implementation
@@ -22,9 +23,71 @@ Hurd servers / VFS libraries are multithreaded.
 
       * [[hurd/libpthread]]
 
+## IRC, freenode, #hurd, 2011-04-20
+
+    <braunr> so basically, a thread should consume only a few kernel resources
+    <braunr> in GNU Mach, it doesn't even consume a kernel stack because only
+      continuations are used
+
+[[microkernel/mach/gnumach/continuation]].
+
+    <braunr> and in userspace, it consumes 2 MiB of virtual memory, a few table
+      entries, and almost no CPU time
+    <svante_> What does "hyperthreaded" mean: Do you have a reference?
+    <braunr> in this context, it just means there are a lot of threads
+    <braunr> even back in the 90s, the expected number of threads could scale
+      up to the thousand
+    <braunr> today, it isn't much impressive any more
+    <braunr> but at the time, most systems didn't have LWPs yet
+    <braunr> and a process was very expensive
+    <svante_> Looks like I have some catching up to do: What is "continuations"
+      and LWP? Maybe I also need a reference to an overview on multi-threading.
+    <ArneBab> Lightweight process?
+      http://en.wikipedia.org/wiki/Light-weight_process
+    <braunr> LWPs are another names for kernel threads usually
+    <braunr> most current kernels support kernel preemption though
+
+[[microkernel/mach/gnumach/preemption]].
+
+    <braunr> which means their state is saved based on scheduler decisions
+    <braunr> unlike continuations where the thread voluntarily saves its state
+    <braunr> if you only have continuations, you can't have kernel preemption,
+      but you end up with one kernel stack per processor
+    <braunr> while the other model allows kernel preemption and requires one
+      kernel stack per thread
+    <svante_> I know resources are limited, but it looks like kernel preemption
+      would be nice to have. Is that too much for a GSoC student?
+    <braunr> it would require a lot of changes in obscure and sensitive parts
+      of the kernel
+    <braunr> and no, kernel preemption is something we don't actually need
+    <braunr> even current debian linux kernels are built without kernel
+      preemption
+    <braunr> and considering mach has hard limitations on its physical memory
+      management, increasing the amount of memory used for kernel stacks would
+      imply less available memory for the rest of the system
+    <svante_> Are these hard limits in mach difficult to change?
+    <braunr> yes
+    <braunr> consider mach difficult to change
+    <braunr> that's actually one of the goals of my stalled project
+    <braunr> which I hope to resume by the end of the year :/
+    <svante_> Reading Wikipedia it looks like LWP are "kernel treads" and other
+      threads are "user threads" at least in IBM/AIX. LWP in Linux is a thread
+      sharing resources and in SunOS they are "user threads". Which is closest
+      for Hurd?
+    <braunr> i told you
+    <braunr> 14:09 < braunr> LWPs are another names for kernel threads usually
+    <svante_> Similar to to the IBM definition then? Sorry for not remembering
+      what I've  been reading.
+
 
 # Design
 
+## Application Programs
+
+### [[glibc/signal/signal_thread]]
+
+## Hurd Servers
+
 See [[hurd/libports]]: roughly using one thread per
 incoming request.  This is not the best approach: it doesn't really make sense
 to scale the number of worker threads with the number of incoming requests, but
@@ -37,7 +100,7 @@ Control*](http://soft.vub.ac.be/~tvcutsem/talks/presentations/T37_nobackground.p
 Tom Van Cutsem, 2009.
 
 
-## IRC, freenode, #hurd, 2012-07-08
+### IRC, freenode, #hurd, 2012-07-08
 
     <youpi> braunr: about limiting number of threads, IIRC the problem is that
       for some threads, completing their work means triggering some action in
@@ -49,7 +112,7 @@ Tom Van Cutsem, 2009.
     <youpi> right
 
 
-## IRC, freenode, #hurd, 2012-07-16
+### IRC, freenode, #hurd, 2012-07-16
 
     <braunr> hm interesting
     <braunr> when many threads are creating to handle requests, they
@@ -134,7 +197,7 @@ Tom Van Cutsem, 2009.
     <braunr> (i still strongly believe those shouldn't be used at all)
 
 
-## IRC, freenode, #hurd, 2012-08-31
+### IRC, freenode, #hurd, 2012-08-31
 
     <braunr> and the hurd is all but scalable
     <gnu_srs> I thought scalability was built-in already, at least for hurd??
@@ -157,7 +220,7 @@ Tom Van Cutsem, 2009.
     <braunr> a very common mistake of the early 90s
 
 
-## IRC, freenode, #hurd, 2012-09-06
+### IRC, freenode, #hurd, 2012-09-06
 
     <braunr> mel-: the problem with such a true client/server architecture is
       that the scheduling context of clients is not transferred to servers
@@ -203,7 +266,7 @@ Tom Van Cutsem, 2009.
       async by nature, will create messages floods anyway
 
 
-# Alternative approaches:
+## Alternative approaches:
 
   * <http://www.concurrencykit.org/>
 
diff --git a/open_issues/multithreading/erlang-style_parallelism.mdwn b/open_issues/multithreading/erlang-style_parallelism.mdwn
index 75539848..4c3651e3 100644
--- a/open_issues/multithreading/erlang-style_parallelism.mdwn
+++ b/open_issues/multithreading/erlang-style_parallelism.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
@@ -148,6 +148,9 @@ IRC, #hurd, 2010-10-05
       they block. but if we want to accept that, there is no point in doing
       this continuation stuff at all -- we could just use a single-threaded
       implementation :-)
+
+[[continuation]].
+
     <sdschulze> Hard solution: do use explicit I/O and invent a
       read_no_pagefault() call.
     <antrik> not sure what you mean exactly. what I would consider is something
diff --git a/open_issues/nice_vs_mach_thread_priorities.mdwn b/open_issues/nice_vs_mach_thread_priorities.mdwn
index 6a890eca..76788a53 100644
--- a/open_issues/nice_vs_mach_thread_priorities.mdwn
+++ b/open_issues/nice_vs_mach_thread_priorities.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -16,74 +17,137 @@ when testing *nice*: [[!debbug 190581]].
 There has been older discussion about this, too, but this is not yet captured
 here.
 
-IRC, #hurd, August 2010
+
+# IRC, freenode, #hurd, 2010-08
 
     <pochu> I'm reading Mach and POSIX documentation to understand the priorities/nice problems
-    <pochu> antrik said it would be better to reimplement everything instead of fixing the current Mach interfaces, though I'm not sure about that yet
+    <pochu> antrik said it would be better to reimplement everything instead of
+      fixing the current Mach interfaces, though I'm not sure about that yet
     <youpi> uh, so he changed his mind?
-    <pochu> it seems POSIX doesn't say nice values should be -20..20, but 0..(2*NZERO - 1)
-    <youpi> he said we could just change the max priority value and be done with it :)
-    <pochu> so we can probably define NZERO to 16 to match the Mach range of 0..31
+    <pochu> it seems POSIX doesn't say nice values should be -20..20, but
+      0..(2*NZERO - 1)
+    <youpi> he said we could just change the max priority value and be done
+      with it :)
+    <pochu> so we can probably define NZERO to 16 to match the Mach range of
+      0..31
     <youpi> s/said/had said previously/
-    <antrik> youpi: POSIX is actually fucked up regarding the definition of nice values
+    <antrik> youpi: POSIX is actually fucked up regarding the definition of
+      nice values
     <antrik> or at least the version I checked was
-    <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just set NZERO to 16 AFAICS: http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html
-    <antrik> it talkes about NZERO and all; making it *look* like this could be defined arbitrarily... but in other places, it's clear that the standard 40 level range is always assumed
-    <antrik> anyways, I totally see no point in deviating from other systems in this regard. it can only cause problems, and gives us no benefits
+    <pochu> antrik: why? this says the range is [0,{NZERO}*2-1], so we can just
+      set NZERO to 16 AFAICS:
+      http://www.opengroup.org/onlinepubs/9699919799/functions/getpriority.html
+    <antrik> it talkes about NZERO and all; making it *look* like this could be
+      defined arbitrarily... but in other places, it's clear that the standard
+      40 level range is always assumed
+    <antrik> anyways, I totally see no point in deviating from other systems in
+      this regard. it can only cause problems, and gives us no benefits
     <cfhammar> it says NZERO should be at least 20 iirc 
     <youpi> agreed
-    <antrik> I don't remember the details; it's been a while since I looked at this
-    <antrik> youpi: changing the number of levels is only part of the issue. I'm not sure why I didn't mention it initially when we discussed this
-    <antrik> youpi: I already concluded years ago that it's not possible to implement nice levels correctly with the current Mach interfaces in a sane fashion
-    <antrik> (it's probably possible, but only with a stupid hack like setting all the thread priorities one by one)
-    <antrik> youpi: also, last time we discussed this, I checked how the nice stuff works currently on Hurd; and concluded that it's so utterly broken, that there is no point in trying to preserve *any* compatibility. I think we can safely throw away any handling that is alread there, and do it over from scratch in the most straightforward fashion
-    <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly what you've just said to be a hack (setting all the thread priorities one by one)
+    <antrik> I don't remember the details; it's been a while since I looked at
+      this
+    <antrik> youpi: changing the number of levels is only part of the
+      issue. I'm not sure why I didn't mention it initially when we discussed
+      this
+    <antrik> youpi: I already concluded years ago that it's not possible to
+      implement nice levels correctly with the current Mach interfaces in a
+      sane fashion
+    <antrik> (it's probably possible, but only with a stupid hack like setting
+      all the thread priorities one by one)
+    <antrik> youpi: also, last time we discussed this, I checked how the nice
+      stuff works currently on Hurd; and concluded that it's so utterly broken,
+      that there is no point in trying to preserve *any* compatibility. I think
+      we can safely throw away any handling that is alread there, and do it
+      over from scratch in the most straightforward fashion
+    <pochu> antrik: I've thought about setting NZERO to 16 and doing exactly
+      what you've just said to be a hack (setting all the thread priorities one
+      by one)
     <pochu> but there seems to be consensus that that's undesirable...
     <pochu> indeed, POSIX says NZERO should be at least 20
-    <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the complexity of setting the thread max priorities individually
-    <pochu> antrik: I don't. would it be too complex? I imagined it would be a simple loop :)
-    <antrik> pochu: in order to prevent race conditions, you have to stop all other threads before obtaining the list of threads, and continue them after setting the priority for each
-    <antrik> I don't even know whether it can be done without interfering with other thread handling... in which case it gets really really ugly
-    <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the priority stuff as appropriate, and will change the tasks code later
-    <antrik> it seems to me that using a more suitable kernel interface will not only be more elegant, but quite possibly actually easier to implement...
-    <pochu> antrik: apparently it's not that hard to change the priority for all threads in a task, see task_priority() in gnumach/kern/task.c
-    <pochu> it looks like the nice test failures are mostly because of the not 1:1 mapping between nice values and Mach priorities
+    <antrik> pochu: BTW, I forgot to say: I'm not sure you appreciate the
+      complexity of setting the thread max priorities individually
+    <pochu> antrik: I don't. would it be too complex? I imagined it would be a
+      simple loop :)
+    <antrik> pochu: in order to prevent race conditions, you have to stop all
+      other threads before obtaining the list of threads, and continue them
+      after setting the priority for each
+    <antrik> I don't even know whether it can be done without interfering with
+      other thread handling... in which case it gets really really ugly
+    <pochu> antrik: btw I'm looking at [gnumach]/kern/thread.[ch], removing the
+      priority stuff as appropriate, and will change the tasks code later
+    <antrik> it seems to me that using a more suitable kernel interface will
+      not only be more elegant, but quite possibly actually easier to
+      implement...
+    <pochu> antrik: apparently it's not that hard to change the priority for
+      all threads in a task, see task_priority() in gnumach/kern/task.c
+    <pochu> it looks like the nice test failures are mostly because of the not
+      1:1 mapping between nice values and Mach priorities
     <marcusb> "Set priority of task; used only for newly created threads."
     <marcusb> there is a reason I didn't fix nice 8 years ago
     <marcusb> ah there is a change_threads option
-    <pochu> marcusb: I'm not sure that comment is correct. that syscall is used by setpriority()
+    <pochu> marcusb: I'm not sure that comment is correct. that syscall is used
+      by setpriority()
     <marcusb> yeah
-    <marcusb> I didn't read further, where it explains the change_threads options
+    <marcusb> I didn't read further, where it explains the change_threads
+      options
     <marcusb> I was shooting before asking questions :)
-    <marcusb> pochu: although there are some bad interactions if max_priorities are set per thread
-    <antrik> pochu: maybe we are talking past each other. my point was not that it's hard to do in the kernel. I was just saying that it would be painful to do from userspace with the current kernel interface
-    <pochu> antrik: you could still use that interface in user space, couldn't you? or maybe I'm misunderstanding...
-    <pochu> cfhammar, antrik: current patch: http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what to do with high-priority threads. are there cases where there should be a thread with a high priority but the task's priority shouldn't be high? e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c
-    <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a higher priority, but then either we raise the task's max_priority if we need a high-prio thread, or we treat them specially (e.g. new field in struct thread), or maybe it's a non-issue because in such cases, all the task is high-prio?
-    <pochu> also I wonder whether I can kill the processor set's max_priority. It seems totally unused (I've checked gnumach, hurd and glibc)
+    <marcusb> pochu: although there are some bad interactions if max_priorities
+      are set per thread
+    <antrik> pochu: maybe we are talking past each other. my point was not that
+      it's hard to do in the kernel. I was just saying that it would be painful
+      to do from userspace with the current kernel interface
+    <pochu> antrik: you could still use that interface in user space, couldn't
+      you? or maybe I'm misunderstanding...
+    <pochu> cfhammar, antrik: current patch:
+      http://emilio.pozuelo.org/~deb/gnumach.patch, main issue is probably what
+      to do with high-priority threads. are there cases where there should be a
+      thread with a high priority but the task's priority shouldn't be high?
+      e.g. what to do with kernel_thread() in [gnumach]/kern/thread.c
+    <pochu> i.e. if tasks have a max_priority, then threads shouldn't have a
+      higher priority, but then either we raise the task's max_priority if we
+      need a high-prio thread, or we treat them specially (e.g. new field in
+      struct thread), or maybe it's a non-issue because in such cases, all the
+      task is high-prio?
+    <pochu> also I wonder whether I can kill the processor set's
+      max_priority. It seems totally unused (I've checked gnumach, hurd and
+      glibc)
     <pochu> (that would simplify the priority handling)
-    <cfhammar> pochu: btw what does your patch do? i can't remember what was decided
-    <pochu> cfhammar: it moves the max_priority from the thread to the task, so raising/lowering it has effect on all of its threads
-    <pochu> it also increases the number of run queues (and thus that of priority levels) from 32 to 40 so we can have a 1:1 mapping with nice values
-    <pochu> cfhammar: btw don't do a full review yet, just a quick look would be fine for now
+    <cfhammar> pochu: btw what does your patch do? i can't remember what was
+      decided
+    <pochu> cfhammar: it moves the max_priority from the thread to the task, so
+      raising/lowering it has effect on all of its threads
+    <pochu> it also increases the number of run queues (and thus that of
+      priority levels) from 32 to 40 so we can have a 1:1 mapping with nice
+      values
+    <pochu> cfhammar: btw don't do a full review yet, just a quick look would
+      be fine for now
     <neal> why not do priorities from 0 to 159
     <neal> then both ranges can be scaled
     <neal> without loss of precision
-    <pochu> neal: there would be from Mach to nice priorities, e.g. a task with a priority of 2 another with 3 would have the same niceness, though their priority isn't really the same
+    <pochu> neal: there would be from Mach to nice priorities, e.g. a task with
+      a priority of 2 another with 3 would have the same niceness, though their
+      priority isn't really the same
     <neal> pochu: sure
-    <neal> pochu: but any posix priority would map to a current mach priority and back
+    <neal> pochu: but any posix priority would map to a current mach priority
+      and back
     <neal> sorry, that's not true
     <neal> a posix priority would map to a new mach priority and bach
-    <neal> and a current mach priority would map to a new mach priority and back
+    <neal> and a current mach priority would map to a new mach priority and
+      back
     <neal> which is I think more desirable than changing to 40 priority levels
-    <pochu> neal> and a current mach priority would map to a new mach priority and back <- why should we care about this?
+    <pochu> neal> and a current mach priority would map to a new mach priority
+      and back <- why should we care about this?
     <neal> to be compatible with existing mach code
     <neal> why gratutiously break existing interfaces?
-    <pochu> they would break anyway, wouldn't them? i.e. if you do task_set_priority(..., 20), you can't know if the caller is assuming old or new priorities (to leave it as 20 or as 100)
+    <pochu> they would break anyway, wouldn't them? i.e. if you do
+      task_set_priority(..., 20), you can't know if the caller is assuming old
+      or new priorities (to leave it as 20 or as 100)
     <neal> you add a new interface
-    <neal> you should avoid changing the semantics of existing interfaces as much as possible
+    <neal> you should avoid changing the semantics of existing interfaces as
+      much as possible
     <pochu> ok, and deprecate the old ones I guess
-    <neal> following that rule, priorities only break if someone does task_set_priority_new(..., X) and task_get_priority ()
+    <neal> following that rule, priorities only break if someone does
+      task_set_priority_new(..., X) and task_get_priority ()
     <neal> there are other users of Mach
     <neal> I'd add a configure check for the new interface
     <neal> alternatively, you can check at run time
@@ -96,102 +160,216 @@ IRC, #hurd, August 2010
     <neal> even apple didn't gratuitously break Mach
     <neal> in fact, it may make sense to see how apple handles this problem
     <pochu> hmm, I hadn't thought about that
-    <pochu> the other thing I don't understand is: "I'd add a configure check for the new interface". a configure check where? in Mach's configure? that doesn't make sense to me
+    <pochu> the other thing I don't understand is: "I'd add a configure check
+      for the new interface". a configure check where? in Mach's configure?
+      that doesn't make sense to me
     <neal> any users of the interface
     <pochu> ok so in clients, e.g. glibc & hurd
     <neal> yes.
-    <antrik> neal: I'm not sure we are winning anything by keeping compatibility with other users of Mach...
-    <antrik> neal: we *know* that to make Hurd work really well, we have to do major changes sooner or later. we can just as well start now IMHO
-    <antrik> keeping compatibility just seems like extra effort without any benefit for us
+    <antrik> neal: I'm not sure we are winning anything by keeping
+      compatibility with other users of Mach...
+    <antrik> neal: we *know* that to make Hurd work really well, we have to do
+      major changes sooner or later. we can just as well start now IMHO
+    <antrik> keeping compatibility just seems like extra effort without any
+      benefit for us
     <guillem> just OOC have all other Mach forks, preserved full compatibility?
     <neal> guillem: Darwin is pretty compatible, as I understand it
-    <antrik> pochu: the fundamental approach of changing the task_priority interface to serve as a max priority, and to drop the notion of max priorities from threads, looks fine
+    <antrik> pochu: the fundamental approach of changing the task_priority
+      interface to serve as a max priority, and to drop the notion of max
+      priorities from threads, looks fine
     <antrik> pochu: I'm not sure about the thread priority handling
-    <antrik> I don't know how thread priorities are supposed to work in chreads and/or pthread
-    <antrik> I can only *guess* that they assume a two-stage scheduling process, where the kernel first decides what process to run; and only later which thread in a process...
-    <antrik> if that's indeed the case, I don't think it's even possible to implement with the current Mach scheduler
-    <antrik> I guess we could work with relative thread priorities if we really want: always have the highest-priority thread run with the task's max priority, and lower the priorities of the other threads accordingly
-    <antrik> however, before engaging into this, I think you should better check whether any of the code in Hurd or glibc actually uses thread priorities at all. my guess is that it doesn't
-    <antrik> I think we could get away with stubbing out thread priority handling alltogether for now, and just use the task priority for all threads
-    <antrik> I agree BTW that it would be useful to check how Darwin handles this
-    <pochu> btw do you know where to download the OS X kernel source? I found something called xnu, but I?m not sure that's it
+    <antrik> I don't know how thread priorities are supposed to work in chreads
+      and/or pthread
+    <antrik> I can only *guess* that they assume a two-stage scheduling
+      process, where the kernel first decides what process to run; and only
+      later which thread in a process...
+    <antrik> if that's indeed the case, I don't think it's even possible to
+      implement with the current Mach scheduler
+    <antrik> I guess we could work with relative thread priorities if we really
+      want: always have the highest-priority thread run with the task's max
+      priority, and lower the priorities of the other threads accordingly
+    <antrik> however, before engaging into this, I think you should better
+      check whether any of the code in Hurd or glibc actually uses thread
+      priorities at all. my guess is that it doesn't
+    <antrik> I think we could get away with stubbing out thread priority
+      handling alltogether for now, and just use the task priority for all
+      threads
+    <antrik> I agree BTW that it would be useful to check how Darwin handles
+      this
+    <pochu> btw do you know where to download the OS X kernel source? I found
+      something called xnu, but I?m not sure that's it
     <antrik> pochu: yeah, that's it
     <antrik> Darwin is the UNIX core of OS X, and Xnu is the actual kernel...
     <pochu> hmm, so they have both a task.priority and a task.max_priority
     <neal> pochu: thoughts?
-    <pochu> neal: they have a priority and a max_priority in the task and in the threads, new threads inherit it from its parent task
-    <pochu> then they have a task_priority(task, priority, max_priority) that can change a task's priorities, and it also changes it for all its threads
+    <pochu> neal: they have a priority and a max_priority in the task and in
+      the threads, new threads inherit it from its parent task
+    <pochu> then they have a task_priority(task, priority, max_priority) that
+      can change a task's priorities, and it also changes it for all its
+      threads
     <neal> how does the global run queue work?
-    <pochu> and they have 128 run queues, no idea if there's a special reason for that number
+    <pochu> and they have 128 run queues, no idea if there's a special reason
+      for that number
     <pochu> neal: sorry, what do you mean?
     <neal> I don't understand the point of the max_priority parameter
     <pochu> neal: and I don't understand the point of the (base) priority ;)
-    <pochu> the max_priority is just that, the maximum priority of a thread, which can be lowered, but can't exceed the max one
-    <pochu> the (base) priority, I don't understand what it does, though I haven't looked too hard. maybe it's the one a thread starts at, and must be <= max_priority
-    <antrik> pochu: it's clearly documented in the manual, as well as in the code your initial patch changes...
+    <pochu> the max_priority is just that, the maximum priority of a thread,
+      which can be lowered, but can't exceed the max one
+    <pochu> the (base) priority, I don't understand what it does, though I
+      haven't looked too hard. maybe it's the one a thread starts at, and must
+      be <= max_priority
+    <antrik> pochu: it's clearly documented in the manual, as well as in the
+      code your initial patch changes...
     <antrik> or do you mean the meaning is different in Darwin?...
     <pochu> I was speaking of Darwin, though maybe it's the same as you say
-    <antrik> I would assume it's the same. I don't think there would be any point in having the base vs. max priority distinction at all, except to stay in line with standard Mach...
-    <antrik> at least I can't see a point in the base priority semantics for use in POSIX systems...
-    <pochu> right, it would make sense to always have priority == max_priority ...
-    <pochu> neal: so max_priority is that maximum priority, and priority is the one used to calculate the scheduled priority, and can be raised and lowered by the user without giving special permissions as long as he doesn't raise it above max_priority
-    <pochu> well this would allow a user to lower a process' priority, and raise it again later, though that may not be allowed by POSIX, so then we would want to have max_priority == priority (or get rid of one of them if possible and backwards compatible)
+    <antrik> I would assume it's the same. I don't think there would be any
+      point in having the base vs. max priority distinction at all, except to
+      stay in line with standard Mach...
+    <antrik> at least I can't see a point in the base priority semantics for
+      use in POSIX systems...
+    <pochu> right, it would make sense to always have priority == max_priority
+      ...
+    <pochu> neal: so max_priority is that maximum priority, and priority is the
+      one used to calculate the scheduled priority, and can be raised and
+      lowered by the user without giving special permissions as long as he
+      doesn't raise it above max_priority
+    <pochu> well this would allow a user to lower a process' priority, and
+      raise it again later, though that may not be allowed by POSIX, so then we
+      would want to have max_priority == priority (or get rid of one of them if
+      possible and backwards compatible)
     <antrik> pochu: right, that's what I think too
-    <antrik> BTW, did I bring up handling of thread priorities? I know that I meant to, but I don't remember whether I actually did...
+    <antrik> BTW, did I bring up handling of thread priorities? I know that I
+      meant to, but I don't remember whether I actually did...
     <pochu> antrik: you told me it'd be ok to just get rid of them for now
-    <pochu> so I'm more thinking of fixing max_priority and (base) priority and leaving thread's scheduling priority as it currently is
+    <pochu> so I'm more thinking of fixing max_priority and (base) priority and
+      leaving thread's scheduling priority as it currently is
     <pochu> s/so/though/
-    <antrik> pochu: well, my fear is that keeping the thread priority handling as ist while changing task priority handling would complicate the changes, while giving us no real benefit...
-    <antrik> though looking at what Darwin did there should give you an idea what it involves exactly...
-    <pochu> antrik: what would you propose, keeping sched_priority == max_priority ?
+    <antrik> pochu: well, my fear is that keeping the thread priority handling
+      as ist while changing task priority handling would complicate the
+      changes, while giving us no real benefit...
+    <antrik> though looking at what Darwin did there should give you an idea
+      what it involves exactly...
+    <pochu> antrik: what would you propose, keeping sched_priority ==
+      max_priority ?
     <pochu> s/keeping/making/
     <antrik> yes, if that means what I think it does ;-)
-    <antrik> and keeping the priority of all threads equal to the task priority for now
-    <antrik> of course this only makes sense if changing it like this is actually simpler than extending the current handling...
-    <antrik> again, I can't judge this without actually knowing the code in question. looking at Darwin should give you an idea...
-    <pochu> I think leaving it as is, making it work with the task's max_priority changes would be easier
-    <antrik> perhaps I'm totally overestimating the amount of changes required to do what Darwin does
-    <antrik> OTOH, carrying around dead code isn't exactly helping the maintainability and efficiency of gnumach...
+    <antrik> and keeping the priority of all threads equal to the task priority
+      for now
+    <antrik> of course this only makes sense if changing it like this is
+      actually simpler than extending the current handling...
+    <antrik> again, I can't judge this without actually knowing the code in
+      question. looking at Darwin should give you an idea...
+    <pochu> I think leaving it as is, making it work with the task's
+      max_priority changes would be easier
+    <antrik> perhaps I'm totally overestimating the amount of changes required
+      to do what Darwin does
+    <antrik> OTOH, carrying around dead code isn't exactly helping the
+      maintainability and efficiency of gnumach...
     <antrik> so I'm a bit ambivalent on this
-    <antrik> should we go for minimal changes here, or use this occasion to simplify things?...
+    <antrik> should we go for minimal changes here, or use this occasion to
+      simplify things?...
     <antrik> I guess it would be good to bring this up on the ML
     <cfhammar> in the context of gsoc i'd say minimal changes
-    <pochu> there's also neal's point on keeping backwards compatibility as much as possible
+    <pochu> there's also neal's point on keeping backwards compatibility as
+      much as possible
     <neal> my point was not backwards compatibility at all costs
     <antrik> I'm still not convinced this is a valid point :-)
     <neal> but to not gratutiously break things
-    <antrik> neal: well, I never suggested breaking things just because we can... I only suggested breaking things to make the code and interface simpler :-)
+    <antrik> neal: well, I never suggested breaking things just because we
+      can... I only suggested breaking things to make the code and interface
+      simpler :-)
     <antrik> I do not insist on it though
     <neal> at that time, we did not know how Mac did it
-    <antrik> I only think it would be good to get into a habit that Mach interfaces are not sacred...
-    <neal> and, I also had a proposal, which I think is not difficult to implement given the existing patch
-    <antrik> but as I said, I do not feel strongly about this. if people feel more confident about a minimal change, I'm fine with that :-)
-    <antrik> neal: err... IIRC your proposal was only about the number of nice levels? we are discussing the interface change necessary to implement POSIX semantics properly
+    <antrik> I only think it would be good to get into a habit that Mach
+      interfaces are not sacred...
+    <neal> and, I also had a proposal, which I think is not difficult to
+      implement given the existing patch
+    <antrik> but as I said, I do not feel strongly about this. if people feel
+      more confident about a minimal change, I'm fine with that :-)
+    <antrik> neal: err... IIRC your proposal was only about the number of nice
+      levels? we are discussing the interface change necessary to implement
+      POSIX semantics properly
     <antrik> or am I misremembering?
-    <pochu> antrik: he argues that with that number of nice levels, we could keep backwards compatibility for the 0..31 levels, and for 0..39 for POSIX compatibility
+    <pochu> antrik: he argues that with that number of nice levels, we could
+      keep backwards compatibility for the 0..31 levels, and for 0..39 for
+      POSIX compatibility
     <antrik> pochu: yes, I remember that part
-    <neal> antrik : My suggestion was: raise the number of nice levels to 160 and introduce a new interface which uses those.  Adjust the old interface to space by 160/32
-    <antrik> neal: I think I said it before: the problem is not *only* in the number of priority levels. the semantics are also wrong. which is why Darwin added a max_priority for tasks
+    <neal> antrik : My suggestion was: raise the number of nice levels to 160
+      and introduce a new interface which uses those.  Adjust the old interface
+      to space by 160/32
+    <antrik> neal: I think I said it before: the problem is not *only* in the
+      number of priority levels. the semantics are also wrong. which is why
+      Darwin added a max_priority for tasks
     <neal> what do you mean the semantics are wrong?
     <neal> I apologize if you already explained this.
-    <antrik> hm... I explained it at some point, but I guess you were not present at that conversation
+    <antrik> hm... I explained it at some point, but I guess you were not
+      present at that conversation
     <neal> I got disconnected recently so I likely don't have it in backlog.
-    <antrik> in POSIX, any process can lower its priority; while only privileged processes can raise it
-    <antrik> Mach distinguishes between "current" and "max" priority for threads: "max" behaves like POSIX; while "current" can be raised or lowered at will, as long as it stays below "max"
+    <antrik> in POSIX, any process can lower its priority; while only
+      privileged processes can raise it
+    <antrik> Mach distinguishes between "current" and "max" priority for
+      threads: "max" behaves like POSIX; while "current" can be raised or
+      lowered at will, as long as it stays below "max"
     <antrik> for tasks, there is only a "current" priority
-    <antrik> (which applies to newly created threads, and optionally can be set for all current threads while changing the task priority)
-    <antrik> glibc currently uses the existing task priorities, which leads to *completely* broken semantics
-    <antrik> instead, we need something like a max task priority -- which is exactly what Darwin added
+    <antrik> (which applies to newly created threads, and optionally can be set
+      for all current threads while changing the task priority)
+    <antrik> glibc currently uses the existing task priorities, which leads to
+      *completely* broken semantics
+    <antrik> instead, we need something like a max task priority -- which is
+      exactly what Darwin added
     <neal> yes
-    <antrik> (the "current" task priority is useless for POSIX semantics as far as I can tell; and regarding thread priorities, I doubt we actually use them at all?...)
+    <antrik> (the "current" task priority is useless for POSIX semantics as far
+      as I can tell; and regarding thread priorities, I doubt we actually use
+      them at all?...)
     <cfhammar> where does a new thread get its initial max_priority from?
     <antrik> cfhammar: from the creator thread IIRC
     <pochu> yes
 
-2010-08-12
 
-    <pochu> my plan is to change the number of priority levels and the threads/tasks priority handling, then add new RPCs to play with them and make the old ones stay compatible, then make glibc use the new RPCs
+## IRC, freenode, #hurd, 2010-08-12
+
+    <pochu> my plan is to change the number of priority levels and the
+      threads/tasks priority handling, then add new RPCs to play with them and
+      make the old ones stay compatible, then make glibc use the new RPCs
+
+
+# IRC, freenode, #hurd, 2012-12-29
+
+    <braunr> and, for a reason that i can't understand, there are less
+      priorities than nice levels, despite the fact mach was designed to run
+      unix systems on top of it ..
+    <youpi> btw, didn't we have a plan to increase that number?
+    <braunr> i have no idea
+    <braunr> but we should :)
+    <youpi> I remember some discussion about it on the list
+
+
+## IRC, freenode, #hurd, 2012-12-31
+
+    <youpi> braunr: btw, we *do* have fixed the nice granularity
+    <youpi> +#define MACH_PRIORITY_TO_NICE(prio) ((prio) - 20)
+    <youpi> in the debian package at least
+    <youpi> ah, no
+    <youpi> it's not applied yet
+    <youpi> so I have the patch under hand, just not applied :)
+    <braunr> but that's a simple shift
+    <braunr> the real problem is that there aren't as many mach priorities as
+      there are nice levels
+    <youpi> that's not really a problem
+    <youpi> we can raise that in the kernel
+    <youpi> the problem is the change from shifted to unshifted
+    <youpi> that brings odd nice values during the upgrade
+    <braunr> ok
+    <braunr> i hope the scheduler code isn't allergic to more priorities :)
+
 
----
+## IRC, freenode, #hurd, 2013-01-02
 
-Another nice issue: [[nice_changes_priority_of_parent_shell]].
+    <braunr> pochu: i see you were working on nice levels and scheduling code
+      some time ago
+    <braunr> pochu: anything new since then ?
+    <pochu> braunr: nope
+    <braunr> pochu: were you preparing it for the gsoc ?
+    <pochu> braunr: can't remember right now, either that or to fix a ftbfs in
+      debian
+    <youpi> iirc it's coreutils which wants proper nice levels
diff --git a/open_issues/open_posix_test_suite.mdwn b/open_issues/open_posix_test_suite.mdwn
index 089ea1b1..5afa6538 100644
--- a/open_issues/open_posix_test_suite.mdwn
+++ b/open_issues/open_posix_test_suite.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2012 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
@@ -10,6 +10,9 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="Open POSIX Test Suite"]]
 
+
+# 2009-07-27
+
 Here's a log of a [Open POSIX Test Suite](http://posixtest.sourceforge.net/)
 run (get sources, `make`, inspect `logfile`); this is from 2009-07-27 HEAD
 sources on a 2009-07-27 Debian GNU/Hurd system.
@@ -2713,3 +2716,10 @@ and restart:
     unexpected error: scheduler 5-4: pthread_attr_setschedpolicy
     functional/threads/schedule/1-2: execution: UNRESOLVED: Output: 
     unexpected error: scheduler 5-5: pthread_setschedparam
+
+
+# IRC, OFTC, #debin-hurd, 2012-12-28
+
+    <pinotree> [...] saw posixtestsuite being completed too \o/
+    <youpi> yep :)
+    <pinotree> (still has a number of failures, but at least can be fully run)
diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn
index 7c66776b..20ae126d 100644
--- a/open_issues/rework_gnumach_ipc_spaces.mdwn
+++ b/open_issues/rework_gnumach_ipc_spaces.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -433,6 +433,8 @@ There is a [[!FF_project 268]][[!tag bounty]] on this task.
       no locking, no preloading before locking, all of this because simple
       locks don't exist on UP, and because the kernel isn't preemptible
 
+[[microkernel/mach/gnumach/preemption]].
+
     <braunr> antrik: and yes, min number is 0, but in that case you don't need
       (space, port) -> right lookups :)
     <braunr> antrik: or put in another way, whichever reasonable structure you
@@ -568,6 +570,9 @@ There is a [[!FF_project 268]][[!tag bounty]] on this task.
     < braunr> and ipc spaces are locked when inserting/allocating names
     < braunr> we normally don't need preloading in gnumach
     < braunr> since there is no preemption nor SMP
+
+[[microkernel/mach/gnumach/preemption]].
+
     < braunr> but in case someone changes that, i'd like the code to be mostly
       ready
     < braunr> and correctly handle those ugly simple locks
diff --git a/open_issues/rpc_stub_generator.mdwn b/open_issues/rpc_stub_generator.mdwn
new file mode 100644
index 00000000..05eb53b8
--- /dev/null
+++ b/open_issues/rpc_stub_generator.mdwn
@@ -0,0 +1,99 @@
+[[!meta copyright="Copyright © 2012 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_mig]]
+
+
+# Originally in context of [[user/jkoenig/java]]
+
+  * [[tschwinge]] has to read about RMI and CORBA.
+
+  * MIG
+
+      * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
+
+          * (Unless you want to make MIG's own code (that is, not the generated
+            code, but MIG itself) look a bit more nice, too.)  ;-)
+
+      * There are also alternatives to MIG.  If there is interest, the following
+        could be considered:
+
+          * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
+            there would be any benefits over MIG, like better modularity (for the
+            backends)?  If we feel like it, we could spend a little bit of time on
+            this.
+
+          * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
+            entirely in C Preprocessor macros.  While this is obviously not
+            directly applicable, perhaps we can get some ideas from it.
+
+          * Anything else that would be worth having a look at?  (What are other
+            microkernels using?)
+
+
+# IRC, freenode, #hurd, 2012-12-27
+
+    <braunr> i'll soon have userspace on x15, and begin system calls, and of
+      course IPC
+    <braunr> and, since i personally have a strong disgust for IDLs, i was
+      thinking of manually writing the RPC "stubs", with helper functions and
+      macros
+    <braunr> what do you think of that ?
+    <pinotree> IDLs could have the advantage you can generate any kind of
+      language output out of them
+    <youpi> I'd not recommend that
+    <youpi> as ugly as IDLs are, they are useful
+    <pinotree> maybe pick something with proper per-arch types and
+      structs... :)
+    <braunr> youpi: what feature do you consider that important in an IDL ?
+    <braunr> i mean important enough to want to keep it
+    <youpi> argument matching between client and server code
+    <braunr> well obviously, but system wide protocols such as the hurd's tend
+      not to change much
+    <youpi> we've still seen bugs about that
+    <youpi> even without changing the protocol
+    <braunr> pinotree: i agree about the language thing, but wrapping libraries
+      also do
+    <braunr> what IDL would you then recommend ?
+    <pinotree> corba! :p
+    * pinotree runs
+    <braunr> well don't run
+    <braunr> it's actually at the top of my list :p
+    <braunr> the parser is free, and allows writing custom backends
+    <braunr> and there is already support for many languages
+    * pinotree some time ago fixed omniorb in debian
+    <pinotree> (to compile on hurd, i mean)
+    <braunr> i thought i could delay this problem some more but it's actually
+      coming quite fast :/
+    <braunr> i suppose it would make sense to use an already popular IDL so
+      that support for other languages is readily available
+    <pinotree> and/or people already know it
+    <braunr> hm that's secondary imo
+    <braunr> it's not that hard to learn an idl (providing it's simple,
+      i.e. not mig-like)
+    <braunr> hm how about google protocol buffers ?
+    <pinotree> wow, not bad at a first glance (never seen it)
+    <pinotree> structs, optional fields, builtin strings
+    <braunr> the nice thing about it is that it focuses on serialization most,
+      but has basic rpc support that allows using whatever communication
+      channel you want
+    <braunr> it may still be overkill for a microkernel based system
+    <pinotree> otoh rpc is everything in a microkernel-based os
+    <braunr> when i say overkill, i mean too slow
+    <pinotree> we still have 1024-sized string_t...
+    <braunr> yes, mig is totally hairy ...
+    <braunr> hum, c++ only, no c :/
+    <pinotree> there seems to be a C compiler, install protobuf-c-compiler
+    <braunr> v0.15, doesn't seem widely used
+    <pinotree> even on 0.14 (currently in debian)
+    <braunr> it also seems to rely on contiguous messages, whereas i want
+      scatter-gather to be used with x15
+    <braunr> once more, i fell back on omg idl
+    <braunr> oh, there is also flick that looks interesting
diff --git a/open_issues/select.mdwn b/open_issues/select.mdwn
index 778af530..391509a9 100644
--- a/open_issues/select.mdwn
+++ b/open_issues/select.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2010, 2011, 2012, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -1631,6 +1631,412 @@ IRC, unknown channel, unknown date:
     <braunr> i'll try the non intrusive mode
 
 
+## IRC, freenode, #hurd, 2012-12-11
+
+    <gnu_srs1> braunr: What is the technical difference of having the delay at
+      io_select compared to mach_msg for one FD?
+    <braunr> gnu_srs1: it's a slight optimization
+    <braunr> instead of doing a send and a receive, the same mach_msg call is
+      used for both
+    <braunr> (for L4 guys it wouldn't be considered a slight optimization :))
+
+
+## IRC, freenode, #hurd, 2012-12-17
+
+    <braunr> tschwinge:
+      http://git.savannah.gnu.org/cgit/hurd/glibc.git/log/?h=rbraun/select_timeout_for_one_fd
+    <braunr> gnu_srs: talking about that, can you explain :
+    <braunr> "- The pure delay case is much faster now, making it necessary to                                                                                                                                                    
+    <braunr> introduce a delay of 1 msec when the timeout parameter is set to
+      zero.                                                                                                                                              
+    <braunr> "
+    <gnu_srs> I meant poll with zero delay needs a delay to make sure the file
+      descriptors are ready. Testing it now.
+    <braunr> for me, the "pure delay" case is the case where there is no file
+      descriptor
+    <braunr> when the timeout is 0 is the non-blocking case
+    <braunr> and yes, you need 1ms for the non-blocking case when there are
+      file descriptors
+    <gnu_srs> sorry bad wording (again)
+    <braunr> (note however that this last "requirement" is very hurd specific,
+      and due to a design issue)
+    <braunr> the work i did six months ago fixes it, but depends on pthreads
+      for correct performances (or rather, a thread library change, but
+      changing cthreads was both difficult and pointless)
+    <braunr> also, i intend to work on io_poll as a replacement for io_select,
+      that fixes the "message storm" (i love these names) caused by dead-name
+      notifications resulting from the way io_select works
+
+
+## IRC, freenode, #hurd, 2012-12-19
+
+    <braunr> tschwinge: i've tested the glibc rbraun/select_timeout_for_one_fd
+      branch for a few days on darnassus now, and nothing wrong to report
+
+
+## IRC, freenode, #hurd, 2012-12-20
+
+    <youpi> braunr: so, shall I commit the single hurd select timeout fix to
+      the debian package?
+    <braunr> youpi: i'd say so yes
+
+
+## IRC, freenode, #hurd, 2013-01-03
+
+    <braunr> gnu_srs: sorry, i don't understand your poll_timeout patch
+    <braunr> it basically reverts mine for poll only
+    <braunr> but why ?
+    <gnu_srs> braunr: It does not revert your select patch, if there is one FD
+      the timeout is at io_select, if not one the timeout is at mach_msg
+    <braunr> but why does it only concern poll ?
+    <braunr> (and why didn't i do it this way in the first place ?)
+    <braunr> (or maybe i did ?)
+    <gnu_srs> there are problems with a timeout of zero for poll, depending on
+      the implementation the FDs can result in not being ready.
+    <braunr> but that's also true with select
+    <gnu_srs> the cases I've tested only have problems for poll, not select
+    <braunr> we'll have to create test cases for both
+    <braunr> but your solution doesn't hold anyway
+    <braunr> our current workaround for this class of problems is to set a
+      lower bound on the timeout to 1
+    <braunr> (which comes from a debian specific patch)
+    <gnu_srs> see the test code i sent,
+      http://lists.gnu.org/archive/html/bug-hurd/2012-12/msg00043.html,
+      test_poll+select.c
+    <braunr> the patch might be incomplete though
+    <braunr> i know, but your solution is still wrong
+    <braunr> see debian/patches/hurd-i386/local-select.diff in the debian
+      eglibc package
+    <gnu_srs> and in that message I have introduced a minimum timeout for poll
+      of 1ms.
+    <braunr> yes but you shouldn't
+    <braunr> this is a *known* bug, and for now we have a distribution-specific
+      patch
+    <braunr> in other words, we can't commit that crap upstream
+    <gnu_srs> well, according to youpi there is a need for a communication to
+      flag when the FDs are ready, not yet implemented.
+    <braunr> i'm not sure what you mean by that
+    <youpi> I don't understand what you refer to
+    <braunr> there is a need for a full round-trip even in the non blocking
+      case
+    <braunr> which is implemented in one of my hurd branches, but awaits
+      pthreads integration for decent scalability
+    <youpi> the only difference between poll and select is that select can stop
+      the loop on error, while poll needs to continue
+    <braunr> youpi: don't you think the glibc select patch is incomplete ?
+    <youpi> incomplete in what direction?
+    <youpi> the minimum 1ms delay is a completely bogus workaround
+    <gnu_srs> youpi:
+      http://lists.gnu.org/archive/html/bug-hurd/2012-11/msg00001.html
+    <youpi> so I wouldn't say it's even completing anything :)
+    <braunr> hm no never mind, it's not
+    <braunr> i thought it missed some cases where the delay made sense, but no
+    <braunr> the timeout can only be 0 if the timeout parameter is non NULL
+    <braunr> gnu_srs: during your tests, do you run with the debian eglibc
+      package (including your changes), or from the git glibc ?
+    <gnu_srs> I run with -37, -38, with my minimum poll changes, my 3 cases,
+      and 3 case-poll updates.
+    <braunr> so you do have the debian patches
+    <braunr> so you normally have this 1ms hack
+    <braunr> which means you shouldn't need to make the poll case special
+    <gnu_srs> A admit the 1ms patch is not possible to submit upstream, but it
+      makes things work (and youpi use it for vim)
+    <braunr> i'll try to reproduce your ntpdate problem with -38 when i have
+      some time
+    <braunr> uh, no, vim actually doesn't use the hack :p
+    <youpi> gnu_srs: it's the contrary: we have to avoid it for vim
+    <gnu_srs>  if (strcmp(program_invocation_short_name, "vi") &&
+      strcmp(program_invocation_short_name, "vim") &&
+      strcmp(program_invocation_short_name, "vimdiff") && !to)
+    <gnu_srs>         to = 1;
+    <youpi> that does what we are saying
+    <braunr> strcmp returns 0 on equality
+    <gnu_srs> aha, OK then
+    <gnu_srs> I don't have that hack in my code. I have tested vim a little,
+      but cannot judge, since I'm not a vi user.
+    <braunr> you don't ?
+    <braunr> you should have it if the package patches were correctly applied
+    <gnu_srs> Maybe somebody else could compile a libc with the 3-split code to
+      test it out?
+    <braunr> that's another issue
+    <gnu_srs> I mean the patch I sent to the list, there the vi{m} hack is not
+      present.
+    <braunr> well obviously
+    <braunr> but i'm asking about the poll_timeout one
+    <gnu_srs> A, OK, it's very easy to test that version too but currently -38
+      maybe has a regression due to some other patch.
+    <braunr> that's another thing we're interested in
+    <gnu_srs> Unfortunately it takes a _long_ time to build a new version of
+      libc (several hours...)
+    <braunr> -38 is already built
+    <gnu_srs> yes, but removing patches one by one and rebuilding.
+    <braunr> but then, the "regression" you mention concerns a package that
+      wasn't really working before
+    <braunr> removing ?
+    <braunr> ah, to identify the trouble carrying one
+    <gnu_srs> ntpdate works with -37, no problem...
+    <gnu_srs> but not with -38
+    <braunr> again, trace it with -38
+    <braunr> to see on what it blocks
+    <gnu_srs> as I wrote yesterday gdb hangs the box hard and rpctrace bugs
+      out, any ideas?
+    <youpi> printf
+    <braunr> gdb from a subhurd
+    <gnu_srs> I'm suspecting the setitimer patch: Without it gdb ntpdate does
+      not freeze hard any longer, bt full: http://paste.debian.net/221491/
+    Program received signal SIGINT, Interrupt.
+    0x010477cc in mach_msg_trap ()
+        at /usr/src/kernels/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+    2       kernel_trap (__mach_msg_trap,-25,7)
+    (gdb) thread apply all bt full
+    
+    Thread 6 (Thread 3158.6):
+    #0  0x010477cc in mach_msg_trap ()
+        at /usr/src/kernels/eglibc/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2
+    No locals.
+    #1  0x01047fc9 in __mach_msg (msg=0x52fd4, option=1282, send_size=0, 
+        rcv_size=0, rcv_name=132, timeout=100, notify=0) at msg.c:110
+            ret = <optimized out>
+    #2  0x010ec3a8 in timer_thread () at ../sysdeps/mach/hurd/setitimer.c:90
+            err = <optimized out>
+            msg = {header = {msgh_bits = 4608, msgh_size = 32, 
+                msgh_remote_port = 0, msgh_local_port = 132, msgh_seqno = 78, 
+                msgh_id = 23100}, return_code = 17744699}
+    
+    setitimer.c:90
+          err = __mach_msg (&msg.header,
+                            MACH_RCV_MSG|MACH_RCV_TIMEOUT|MACH_RCV_INTERRUPT,
+                            0, 0, _hurd_itimer_port,
+                            _hurd_itimerval.it_value.tv_sec * 1000 +
+                            _hurd_itimerval.it_value.tv_usec / 1000,
+                            MACH_PORT_NULL);
+
+[[alarm_setitimer]].
+
+    <braunr> gdb ?
+    <braunr> i thought ntpdate was the program freezing
+    <gnu_srs> the freeze is due to -38
+    <braunr> yes we know that
+    <braunr> but why do you say "gdb ntpdate" instead of "ntpdate" ?
+    <gnu_srs> yes, ntpdate freezes: without gdb kill -9 is OK, with gdb it
+      freezes hard (with setitimer pacth).
+    <braunr> we don't care much about the kill behaviour
+    <braunr> ntpdate does indeed makes direct calls to setitimer
+    <gnu_srs> without the setitimer patch: without gdb ntpdate freezes (C-c is
+      OK), with gdb C-c gives the paste above
+    <braunr> sorry i don't understand
+    <braunr> *what* is the problem ?
+    <youpi> there are two of them
+    <youpi> ntpdate freezing
+    <youpi> gdb freezing
+    <braunr> ok
+    <youpi> he's saying gdb freezing is due to the setitimer patch
+    <braunr> yes that's what i understand now
+    <braunr> what he said earlier made me think ntpdate was freezing with -38
+    <gnu_srs> better: ntpdate hangs, gdb ntpdate freezes (with the setitimer
+      patch)
+    <braunr> what's the behaviour in -37, and then what is the behaviour with
+      -38 ?
+    <braunr> (of both actions, so your answer should give us four behaviours)
+    <youpi> gnu_srs: what is the difference between "hangs" and "freezes" ?
+    <gnu_srs> -37 no problem, both with and without gdb.
+    <braunr> you mean ntpdate doesn't freeze with -37, and does with -38 ?
+    <gnu_srs> hangs: kill -9 is sufficient, freezes: reboot, checking file
+      system etc
+    <braunr> and i really mean ntpdate, not gdb whatever
+    <gnu_srs> the ntpdate hang (without the setitimer patch) in -38 can be due
+      to the poll stuff: Have to check further with my poll patch...
+
+
+## IRC, freenode, #hurd, 2013-01-04
+
+    <gnu_srs> Summary of the eglibc-2.13-38 issues: without the
+      unsubmitted-setitimer_fix.diff patch and with
+    <gnu_srs> my poll_timeout.patch fix in
+      http://lists.gnu.org/archive/html/bug-hurd/2012-12/msg00042.html
+    <gnu_srs> ntpdate works again :)
+    <gnu_srs> please consider reworking the setitimer patch and add a poll case
+      in hurdselect.c:-D 
+    <gnu_srs> Additional info: vim prefers to use select before poll,. With the
+      proposed changes (small,3-split),
+    <gnu_srs> only poll is affected by the 1ms default timeout, i.e. the
+      current vi hack is no longer needed.
+    <braunr> gnu_srs: the setitimer patch looks fine, and has real grounds
+    <braunr> gnu_srs: your poll_timeout doesn't
+    <braunr> so unless you can explain where the problem comes from, we
+      shouldn't remove the setitimer patch and add yours
+    <braunr> in addition
+    <braunr> 09:30 < gnu_srs> only poll is affected by the 1ms default timeout,
+      i.e. the current vi hack is no longer needed.
+    <braunr> that sentence is complete nonsense
+    <braunr> poll and select are implemented using the same rpc, which means
+      they're both broken
+    <braunr> if the vi hack isn't needed, it means you broke every poll user
+    <braunr> btw, i think your ntpdate issue is very similar to the gitk one
+    <braunr> gitk currently doesn't work because of select/poll
+    <braunr> it does work fine with my hurd select branch though
+    <braunr> which clearly shows a more thorough change is required, and your
+      hacks won't do any good (you may "fix" ntpdate, and break many other
+      things)
+    <gnu_srs> braunr: Why don't you try ntpdate yourself on -38 (none of my
+      patches applied)
+    <braunr> you're missing the point
+    <braunr> the real problem is the way select/poll is implemented, both at
+      client *and* server sides
+    <gnu_srs> 09:30 etc: The current implementation is slower than the 3-way
+      patch. Therefore it in not needed in the current implementation (I didn't
+      propose that either)
+    <braunr> hacks at the client side only are pointless, whatever you do
+    <braunr> slower ?
+    <braunr> it's not about performance but correctness
+    <braunr> your hack *can't* solve the select/poll correctness issue
+    <gnu_srs> yes, slower on my kvm boxes...
+    <braunr> so it's normal that ntpdate and other applications such as gitk
+      are broken
+    <braunr> if you try to fix it by playing with the timeout, you'll just
+      break the applications that were fixed in the past by playing with the
+      timeout another way
+    <braunr> can you understand that ?
+    <gnu_srs> forget the timeout default, it's a side issue.
+    <braunr> the *real* select/poll issue is that non blocking calls
+      (timeout=0) don't have the time to make a full round trip at the server
+    <braunr> no it's not, it's the whole problem
+    <braunr> some applications work with a higher timeout, some like gitk don't
+    <braunr> ntpdate might act just the same
+    <gnu_srs> yes of course, and I have not addressed this problem either, I'm
+      mostly interested in the 3-way split.
+    <braunr> well, it looks like you're trying to ..
+    <gnu_srs> to be able to submit my poll patches (not yet published)
+    <braunr> i suggest you postpone these changes until the underlying
+      implementation works
+    <braunr> i strongly suspect the split to be useless
+    <braunr> we shouldn't need completely different paths just for this
+      conformance issue
+    <braunr> so wait until select/poll is fixed, then test again
+    <gnu_srs> Read the POSIX stuff: poll and select are different.
+    <braunr> i know
+    <braunr> their expected behaviour is
+    <braunr> that's what needs to be addressed
+    <braunr> but you can't do that now, because there are other bugs in the way
+    <braunr> so you'll have a hard time making sure your changes do fix your
+      issues, because the problems might be cause by the other problems
+    <gnu_srs> since you are the one who knows best, why don't you implement
+      everything yourself.
+    <braunr> well, i did
+    <braunr> and i'm just waiting for the pthreads hurd to spread before
+      adapting my select branch
+
+[[libpthread]].
+
+    <braunr> it won't fix the conformance issue, but it will fix the underlying
+      implementation (the rpc)
+    <braunr> and then you'll have reliable results for the tests you're
+      currently doing
+    <gnu_srs> why not even trying out the cases I found to have problems??
+    <braunr> because i now know why you're observing what you're observing
+    <braunr> i don't need my eyes to see it to actually imagine it clerly
+    <braunr> when i start gitk and it's hanging, i'm not thinking 'oh my, i
+      need to hack glibc select/poll !!!'
+    <braunr> because i know the problem
+    <braunr> i know what needs to be done, i know how to do it, it will be done
+      in time
+    <braunr> please try to think the same way ..
+    <braunr> you're fixing problems by pure guessing, without understanding
+      what's really happenning
+    <gnu_srs> (10:59:17 AM) braunr: your hack *can't* solve the select/poll
+      correctness issue: which hack?
+    <braunr> "please consider removing setitimer because it blocks my ntpdate"
+    <braunr> gnu_srs: all your select related patches
+    <braunr> the poll_timeout, the 3-way split, they just can't
+    <braunr> changes need to be made at the server side too
+    <braunr> you *may* have fixed the conformance issue related to what is
+      returned, but since it get mixed with the underlying implementation
+      problems, your tests aren't reliable
+    <gnu_srs> well some of the test code is from gnulib, their code is not
+      reliable?
+    <braunr> their results aren't
+    <braunr> why is that so hard to understand for you ?
+    <gnu_srs> (11:08:05 AM) braunr: "please consider removing setitimer because
+      it blocks my ntpdate": It's not my ntpdate, it's a program that fails to
+      run on -38, but does on -37!
+    <braunr> it doesn't mean glibc -37 is right
+    <braunr> it just means the ntpdate case seems to be handled correctly
+    <braunr> a correct implementation is *ALWAYS* correct
+    <braunr> if there is one wrong case, it's not, and we know our select/poll
+      implementation is wrong
+    <gnu_srs> no of course not, and the ntpdate implementation is not correct?
+      file a bug upstream then.
+    <braunr> you're starting to say stupid things again
+    <braunr> ntpdate and gnulib tests can't be right if they use code that
+      isn't right
+    <braunr> it doesn't mean they'll always fail either, the programs that fail
+      are those for which select/poll behaves wrong
+    <braunr> same thing for setitimer btw
+    <braunr> we know it was wrong, and i think it was never working actually
+    <gnu_srs> where are the missing test cases then? maybe you should publish
+      correct code so we can try it out?
+    <braunr> i have, but there are dependencies that prevent using it right now
+    <braunr> which is why i'm waiting for pthreads hurd to spread
+    <braunr> pthreads provide the necessary requirements for select to be
+      correctly implemented at server side
+    <gnu_srs> well conformance with your code could be tested on Linux,
+      kFreeBSD, etc
+    <braunr> ?
+    <braunr> i'm not writing test units
+    <gnu_srs> /code/test code/
+    <braunr> the problem is *NOT* the test code
+    <braunr> the problem is some of our system calls
+    <braunr> it's the same for ntpdate and gitk and all other users
+    <gnu_srs> then the gnulib, ntpdate, gitk code is _not_ wrong
+    <braunr> no, but their execution is, and thus their results
+    <braunr> which is ok, they're tests
+    <braunr> they're here precisely to tell us if one case works
+    <braunr> they must all pass to hope their subject is right
+    <braunr> so, again, since there are several problems with our low level
+      calls, you may have fixed one, but still suffer from others
+    <braunr> so even if you did fix something, you may not consider the test
+      failure as an indication that your fix is wrong
+    <braunr> but if you try to make your changes fix everything just to have
+      results that look valid, it's certain to fail, since you only fix the
+      client side, and it's *known* the server side must be changed too
+    <gnu_srs> do you consider unsubmitted-single-hurdselect-timeout.diff and
+      local-select.diff a hack or not?
+    <braunr> the first isn't, since it fixes the correctness of the call for
+      one case, at the cost of some performance
+    <braunr> the second clearly is
+    <braunr> which is the difference between unsubmitted-* and local-*
+    <gnu_srs> and my proposal to modify the first is a hack?
+    <braunr> yes
+    <braunr> it reverts a valid change to "make things work" whereas we know
+      the previous behaviour was wrong
+    <braunr> that's close to the definition of a hack
+    <gnu_srs> "make things work" meaning breaking some applications?
+    <braunr> yes
+    <braunr> in this case, those using poll with one file descriptor and
+      expecting a timeout, not twice the timeout
+    <braunr> well, your change isn't really a revert
+    <braunr> hum yes actually it is
+    <gnu_srs> the timeout is correct
+    <braunr> no, it looks correct
+    <braunr> how did you test it ?
+    <braunr> and same question as yesterday: why only poll ?
+    <gnu_srs> see the code I mentioned before
+    <braunr> no i won't look
+    <braunr> it doesn't explain anything
+    <gnu_srs> I have not found any problems with select, only poll (yes, this
+      is a user perspective)
+    <braunr> that's what i call "pure guessing"
+    <braunr> you just can't explain why it fixes things
+    <braunr> because you don't know
+    <braunr> you don't understand what's really happening in the system
+    <braunr> there is a good idea in your change
+    <braunr> but merely for performance, not correctness
+    <braunr> (your change makes it possible to save the mach_msg receive if the
+      io_select blocked, which is good, but not required)
+
+See also [[alarm_setitimer]].
+
+
 # See Also
 
 See also [[select_bogus_fd]] and [[select_vs_signals]].
diff --git a/open_issues/telnet_session_crash.mdwn b/open_issues/telnet_session_crash.mdwn
new file mode 100644
index 00000000..70b29b0f
--- /dev/null
+++ b/open_issues/telnet_session_crash.mdwn
@@ -0,0 +1,18 @@
+[[!meta copyright="Copyright © 2012 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]]."]]"""]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-12-16
+
+    <youpi> oh, we got a "got working by itself" fix
+    <youpi> in the past telnetting, logging, and pressing ^C would kill the
+      telnet session for some reason
+    <youpi> (if done too early, like only 10s after connexion)
+    <youpi> that's no more for some reason
diff --git a/open_issues/term_blocking.mdwn b/open_issues/term_blocking.mdwn
index 0ed0b4df..1c8816e1 100644
--- a/open_issues/term_blocking.mdwn
+++ b/open_issues/term_blocking.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009, 2011, 2012 Free Software Foundation,
+[[!meta copyright="Copyright © 2009, 2011, 2012, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -307,6 +307,27 @@ In context of the [[select]] issue.
     <antrik> bash
 
 
+## IRC, freenode, #hurd, 2012-12-27
+
+    <youpi> we however have a similar symptom with screen
+    <youpi> shells don't terminate
+    <braunr> yes
+    <youpi> or at least the window doesn't close
+    <braunr> the screen problem is the same as the term servers not being properly closed
+    <youpi> k
+    <braunr> that one is still on my todo list
+    <braunr> and not easy
+    <youpi> like so many small items on the TODO lists :)
+    <braunr> that one is an important one :)
+    <braunr> because we're still using legacy pty, the number of terms is
+      limited
+    <braunr> which means at some point we can't log in any more using them
+    <braunr> (i regularly kill pty terms on darnassus to avoid that)
+    <braunr> it prevents screen and rsyslogd iirc from working correctly, which
+      is very annoying
+    <braunr> there may be other issues
+
+
 # Formal Verification
 
 This issue may be a simple programming error, or it may be more complicated.
diff --git a/open_issues/virtualization.mdwn b/open_issues/virtualization.mdwn
index 343f624a..10cf73db 100644
--- a/open_issues/virtualization.mdwn
+++ b/open_issues/virtualization.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
@@ -44,3 +44,5 @@ An index of things to work on w.r.t. virtualization.
   * [[File_Systems]]
 
   * [[Networking]]
+
+  * [[remap_root_translator]]
diff --git a/open_issues/virtualization/remap_root_translator.mdwn b/open_issues/virtualization/remap_root_translator.mdwn
new file mode 100644
index 00000000..3cb574ae
--- /dev/null
+++ b/open_issues/virtualization/remap_root_translator.mdwn
@@ -0,0 +1,97 @@
+[[!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_hurd]]
+
+
+# IRC, freenode, #hurd, 2013-01-05
+
+    <youpi> so we have a "remap" root translator?
+    <youpi> I  mean this:
+    <youpi> I'd run my shell in a subhurd whose only difference is that the
+      root is not the system's root, but my own
+    <youpi> which catches accesses to /servers/socket/2 for instance
+    <youpi> but leaves the rest flow through the system's root
+    <braunr> there is just boot, i don't think it can do that
+    <youpi> it'd be useful to have that
+    <youpi> it'd be a very useful feature
+    <youpi> to use another tcp/ip stack etc.
+    <braunr> what happens when translators need to locate other translators
+      used by the client ?
+    <youpi> can't it tell the client to ask the real system's root?
+    <youpi> (with the same path)
+    <youpi> I don't remember the exact reply name
+    <braunr> hum, it's getting too fuzzy for my head :p
+    <youpi> well, I mean it's just like translator entries in an ext2fs
+    <youpi> ext2fs replies "not me, this one"
+    <braunr> but what if e.g. a user has its own pflocal, and when calling
+      another translator, that one wants to contact the pflocal used by the
+      client ?
+    <youpi> ah, that won't work of course
+    <braunr> do we actually have such cases btw ?
+    <braunr> procfs perhaps
+    <youpi> I don't think we'd want it actually
+    <braunr> but isn't that required sometimes ?
+    <youpi> inside a shell script, yes
+    <braunr> for example, a storeio translator could ask about the priority
+      properties of the client to proc
+    <youpi> but I don't remember a case where an external translator would need
+      the access
+    <youpi> well, that's actually what we want
+    <youpi> we don't want to fool the storeio with user-provided data :)
+    <braunr> yes
+    <youpi> unless the user starts the storeio himself, in which case he will
+      have to re-root it
+    <braunr> so it has to locate the right translator, despite not using the
+      remap root translator
+    <youpi> err, it will already
+    <youpi> by just using the system's path
+    <braunr> ?
+    <youpi> maybe you need to say exactly what "it" and "right" are :)
+    <braunr> ok, let's imagine your previous example with a subhurd and pfinet
+    <braunr> the remap translator would imply that users from the subhurd
+      *directly* access all services from the main hurd, except when routed
+      otherwise by the remap translator to pfinet
+    <youpi> by "directly", I mean asking the remap translator, which gives as
+      answer "not me, the root"
+    <braunr> now, what if a translator in the main hurd wants e.g. network
+      stats from pfinet, it will ask the main one, not the one obtained through
+      remap
+    <braunr> yes
+    <youpi> that's completely fine
+    <braunr> ah
+    <braunr> that's fine if the results don't matter
+    <youpi> to get network stats from the user pfinet you'd have to be inside
+      the shell using the remap translator
+    <braunr> otherwise they're inconsistent
+    <braunr> yes
+    <youpi> I don't see why you'd want to get the pfinet stats from outside
+    <youpi> you mean ethernet board usage?
+    <braunr> service interactions
+    <braunr> i can't think of anything relevant with pfinet
+    <braunr> but imagine pflocal and credentials
+    <youpi> I believe that'd still be ok
+    <youpi> i.e. things outside the remap want to know the actual system things
+    <youpi> while things inside want to know the remapped things
+    <youpi> and you need that to avoid getting fooled by the user remapping
+    <braunr> for credentials, i think it works because the client provides
+      rights, so it would provide rights to the remapped translators in this
+      case
+    <braunr> this would need to be generalized
+    <youpi> I believe it's already general
+    <braunr> well no
+    <braunr> procfs for example will always talk to the "true" proc server
+    <youpi> sure
+    <youpi> that's what I want from the outside
+    <youpi> if the user, from the inside, wants another view, he'll have to
+      start another procfs
+    <youpi> his own one
+    <braunr> ok
+    <youpi> attached to the remapping
diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn
index fd12987e..73982239 100644
--- a/user/jkoenig/java.mdwn
+++ b/user/jkoenig/java.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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
@@ -467,29 +467,7 @@ IRC, freenode, #hurd, 2011-08-17:
 
 ##### Open Items
 
-  * [[tschwinge]] has to read about RMI and CORBA.
-
-  * MIG
-
-      * Hacking [[microkernel/mach/MIG]] shouldn't be too difficult.
-
-          * (Unless you want to make MIG's own code (that is, not the generated
-            code, but MIG itself) look a bit more nice, too.)  ;-)
-
-      * There are also alternatives to MIG.  If there is interest, the following
-        could be considered:
-
-          * FLICK ([[!GNU_Savannah_task 5723]]).  [[tschwinge]] has no idea yet if
-            there would be any benefits over MIG, like better modularity (for the
-            backends)?  If we feel like it, we could spend a little bit of time on
-            this.
-
-          * For [[microkernel/Viengoos]], Neal has written a RPC stub generator
-            entirely in C Preprocessor macros.  While this is obviously not
-            directly applicable, perhaps we can get some ideas from it.
-
-          * Anything else that would be worth having a look at?  (What are other
-            microkernels using?)
+  * [[open_issues/RPC_stub_generator]]
 
   * `mach_msg`