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

12 files changed, 33 insertions, 24 deletions

diff --git a/glibc/debugging/ld_so_console.mdwn b/glibc/debugging/ld_so_console.mdwn
index 286fcd64..53199ee1 100644
--- a/glibc/debugging/ld_so_console.mdwn
+++ b/glibc/debugging/ld_so_console.mdwn
@@ -19,3 +19,6 @@ simple [[dl-sysdep.c.patch]] to get access to the Mach console.
 
 Can this be integrated with the other debugging printf functions from
 `elf/dl-misc.c` (`_dl_debug_vdprintf`) ([[!taglink open_issue_glibc]])?
+
+Recently (January 2013), the mach_print system call was added to GNU Mach.
+It is available when the kernel is built with the in-kernel kdb debugger.
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index c506861a..94dd946a 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -175,6 +175,9 @@ See `rpctrace --help` about how to use it.
           /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
           trace_and_forward: Assertion `reply_type == 18' failed.
 
+This assertion is actually caused by using the io_select interface, which creates
+a send right instead of a send-once right for the reply port (IIRC).
+
 
 # See Also
 
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 65361ff4..bc43644f 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -138,6 +138,8 @@ small backend stores, like floppy devices.
       breaks performance on the hurd
     <braunr> and 30 seems like a reasonable amount (better than 5 at least)
 
+That would be a nice improvement, but only after writeback throttling is implemented.
+
 
 # Documentation
 
diff --git a/hurd/translator/ext2fs/page_cache.mdwn b/hurd/translator/ext2fs/page_cache.mdwn
index e8a964ed..c129a98e 100644
--- a/hurd/translator/ext2fs/page_cache.mdwn
+++ b/hurd/translator/ext2fs/page_cache.mdwn
@@ -29,3 +29,7 @@ This is not at all specific to ext2fs, so should be integrated elsewhere.
       memory?
     <youpi> Tekk_: yes
     <Tekk_> awesome. I was worried :)
+
+Actually, ext2fs doesn't contain its page cache (the virtual and physical
+memory counters do not take the cache size into account). But it must allocate
+descriptors for the cached content.
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 42ee3c55..826467da 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -57,21 +57,6 @@ Quite the same, but with static IPv6 address assignment:
 Amongst other things, support for [[IOCTL]]s is missing.
 
 
-## IRC, freenode, #hurd, 2012-12-10
-
-[[!tag open_issue_hurd]]
-
-    <braunr> looks like pfinet -G option doesn't work
-    <braunr> if someone is interested in fixing this (it concerns static IPv6
-      routing)
-    <braunr> youpi: have you ever successfully used pfinet with global
-      statically configured ipv6 addresses ?
-    <youpi> never tried
-    <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 :(
@@ -136,6 +121,8 @@ Amongst other things, support for [[IOCTL]]s is missing.
     <youpi> ok, enabling ALLMULTI was enough to fix it
     <youpi> you can ping6 2001:910:1059:2:5054:00ff:fe12:3456 :)
 
+Indeed, IPv6 now works properly, and the very machine hosting this wiki
+(darnassus.sceen.net) can be reached with that protocol.
 
 ## IRC, freenode, #hurd, 2013-01-13
 
diff --git a/open_issues/address_space_memory_mapping_entries.mdwn b/open_issues/address_space_memory_mapping_entries.mdwn
index caf447dd..10494cc5 100644
--- a/open_issues/address_space_memory_mapping_entries.mdwn
+++ b/open_issues/address_space_memory_mapping_entries.mdwn
@@ -17,3 +17,5 @@ IRC, freenode, #hurd, 2011-05-07
       linked list
     <braunr> a bare linked list
     <braunr> which makes faults and page cache lookups even slower
+
+A red-black tree was added to VM maps to speed up lookups.
diff --git a/open_issues/alarm_setitimer.mdwn b/open_issues/alarm_setitimer.mdwn
index 5999808c..a1c8a7d3 100644
--- a/open_issues/alarm_setitimer.mdwn
+++ b/open_issues/alarm_setitimer.mdwn
@@ -22,6 +22,7 @@ for a signal, while on GNU/Hurd it gets a new alarm and exits.
 
 [[alrm.c]]
 
+This issue was recently fixed (around January 2013).
 
 # IRC, freenode, #hurd, 2012-07-29
 
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 3e585876..a461d71b 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -173,6 +173,9 @@ Need more stuff like that.
     <abique> is it M:N ?
     <youpi> libthreads, actually
     <youpi> yes
+
+Actually, the Hurd has never used an M:N model. Both libthreads (cthreads) and libpthread use an 1:1 model.
+
     <abique> nice
     <abique> is the task scheduler in the kernel ?
     <youpi> the kernel thread scheduler, yes, of course
diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
index afdcfb73..12201f51 100644
--- a/open_issues/benefits_of_a_native_hurd_implementation.mdwn
+++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
@@ -120,6 +120,12 @@ IRC, #hurd, 2010-12-28
     [...]
     <braunr> kilobug: right, a monolithick kernel is less folt-tolerant than a
       well designed/implemented microkernel based os
+
+It turns out that it is perfectly possible to isolate services running in the
+same address space, as it was done in projects such as Singularity, the idea
+being that the code is verified through static analysis when installed (but
+this requires a language other than C).
+
     <kilobug> braunr: well, the Hurd is buggy nowadays, but things like an
       ext2fs translator doing a segfault and being restarted is a
       fault-tolerance that would be almost impossible to have in Linux
diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn
index 562ccd83..e420610e 100644
--- a/open_issues/multiprocessing.mdwn
+++ b/open_issues/multiprocessing.mdwn
@@ -54,12 +54,6 @@ IRC, freenode, #hurd, 2011-07-26
     < braunr> thread migration already takes into account smt, cores, and numa
     < braunr> it's hard to do something better
     < braunr> (here, thread migration means being dispatched on another cpu)
-    < braunr> some systems like dragonflybsd go as far as to pin threads on one
-      processor for their entire lifetime
-    < braunr> in order to have rcu-like locking almost everywhere
-    < braunr> (you could argue it's less efficient since in the worst case
-      everything runs on the same cpu, but it's very unlikely, and in practice
-      most patterns are well balanced)
 
 
 debian-hurd list
diff --git a/sandbox.mdwn b/sandbox.mdwn
index b90e8160..bb5939c8 100644
--- a/sandbox.mdwn
+++ b/sandbox.mdwn
@@ -40,3 +40,5 @@ Bulleted list
 ---
 
 UTF-8 testing: © Queensrÿche ¿ Ø ß ®
+
+So, let's see how it behaves ...
diff --git a/user/musial.mdwn b/user/musial.mdwn
index dee4588a..77a32058 100644
--- a/user/musial.mdwn
+++ b/user/musial.mdwn
@@ -8,8 +8,10 @@ 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]]."]]"""]]
 
-Robert Musial - Cleveland, OH
+~musial (Robert Musial) - Cleveland, OH
 
-musial/at/gnu/dot/org
+email: musial at gnu dot org
 
-http://musial.sollux.net
+http://mu5141.com
+
+Join the FSF! - http://www.fsf.org/register_form?referrer=9143