Merge remote-tracking branch 'fp/master'

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

7 files changed, 153 insertions, 10 deletions

diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index e7fa81ec..a5c1a6e9 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -175,8 +175,12 @@ See `rpctrace --help` about how to use it.
           /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
           trace_and_forward: Assertion `reply_type == 18' failed.
 
-This assertion is actually caused by using the io_select interface, which creates
-a send right instead of a send-once right for the reply port (IIRC).
+    This assertion is actually caused by using the io_select interface, which creates
+    a send right instead of a send-once right for the reply port (IIRC).
+
+      * IRC, OFTC, #debian-hurd, 2013-03-14
+
+            <youpi> uhu, there's a TODO just above that assertion :)
 
 
 # See Also
diff --git a/hurd/libihash.mdwn b/hurd/libihash.mdwn
index d6b8e8b6..be20fa58 100644
--- a/hurd/libihash.mdwn
+++ b/hurd/libihash.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2010, 2011, 2012 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2009, 2010, 2011, 2012, 2013 Free Software
+Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -19,19 +19,26 @@ License|/fdl]]."]]"""]]
 
   * hurd-l4 libhurd-ihash
 
+
+# Open Issues
+
   * [[viengoos libhurd-ihash|microkernel/viengoos/projects/new_hash_function]]
 
-    IRC, unknown channel, unknown date
+    IRC, freenode, #hurd, 2008/2009
 
         <neal> so, we need a new ihash implementation
         <neal> marcusb: When 80% full, the collision rate is very high.
         <neal> marcusb: I tested using 512mb / 4096 entries
-        <neal> marcusb: Changing the load factor to 30% resulted in my program running more than an order of magnitude faster.
+        <neal> marcusb: Changing the load factor to 30% resulted in my program
+          running more than an order of magnitude faster.
         <marcusb> yeah, it shouldn't get so full
         <marcusb> don't we do an exponential back-off in the array size?
         <marcusb> of course it's clear we can do much better
         <marcusb> the ihash algo is very simple
-        <marcusb> I'm not even sure it makes much sense to have a generic library
+        <marcusb> I'm not even sure it makes much sense to have a generic
+          library
+
+  * [[community/gsoc/project_ideas/object_lookups]]
 
 
 # Alternatives?
diff --git a/hurd/libps.mdwn b/hurd/libps.mdwn
new file mode 100644
index 00000000..05ab3ad1
--- /dev/null
+++ b/hurd/libps.mdwn
@@ -0,0 +1,27 @@
+[[!meta copyright="Copyright © 2013 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+`libps` provides an API for accessing process information.  An alternative is a
+[[Linux-compatible `/proc` filesystem|translator/procfs]].
+
+
+# IRC, OFTC, #debian-hurd, 2013-03-09
+
+[[!tag open_issue_documentation]]
+
+    <Steap> what's the difference between PSTAT_STATE_P_STOP and
+      PSTAT_STATE_T_HALT in libps/ps.h ?
+    <youpi> Steap: from reading the gnumach source, it seems halted threads are
+      thread which have finished they work but not finished terminating yet
+    <youpi> while STOP is the standard preempted state
+    <youpi> i.e. not sleeping, but have handed cpu to another thread
+    <Steap> youpi: thanks. Is this "halted" state similar to anything in Linux
+      ?
+    <youpi> TASK_DEAD, probably
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index bc43644f..a89b40b1 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -89,6 +89,37 @@ small backend stores, like floppy devices.
     <youpi> which can be quite probable
 
 
+##### IRC, freenode, #hurd, 2013-03-19
+
+    <braunr> youpi: i'm back on polishing the large store patch
+    <braunr> did you remember seeing something else than the bzero/memset
+      out-of-scope changes ?
+    <braunr> (i mean, readily noticeable)
+    <youpi> I don't remember
+    <braunr> ok
+    <braunr> the original code already assumes mmap succeeds
+    <braunr> is it ok to consider the patch can do the same ?
+    <youpi> I'd say so
+    <braunr> ok
+    <braunr> youpi: actually, it looks like a good part of the patch isn't
+      related to large stores
+    <braunr> for example, in ext2fs/inode.c, there are calls to
+      dino_ref/dino_deref
+    <youpi> hum
+    <braunr> i'm not sure at all these have anything to do with handling large
+      stores
+    <youpi> but dino_ref is introduced by this patch, isn't it?
+    <braunr> it replaces dino
+    <youpi> yes, it replaces it because the dino() approach can't work beyond
+      2GiB
+    <braunr> i see
+    <braunr> youpi: i'd like to replace the recursive call to
+      disk_cache_block_ref with a goto, is that fine with you ?
+    <youpi> looks ok to me
+    <youpi> better than relying on tail recursion
+    <braunr> that's the idea :)
+
+
 #### [[libpager]] API change
 
 ##### IRC, freenode, #hurd, 2013-03-04
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 50b5dfc2..3232e0cc 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -1,13 +1,58 @@
-[[!meta copyright="Copyright © 2000, 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2000, 2008, 2013 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
 document under the terms of the GNU Free Documentation License, Version 1.2 or
 any later version published by the Free Software Foundation; with no Invariant
 Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
-is included in the section entitled
-[[GNU Free Documentation License|/fdl]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 The `pfinet` server is a hacked Linux internet implementation with a glue layer
 translating between the Hurd [[RPC]]s and the middle layer of the Linux
 implementation.
+
+
+# Bugs
+
+## Those Listed on [[Open_Issues]]
+
+## [[IPv6]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+    <braunr> youpi: there are indeed historical bugs with small packets and
+      tcp_nodelay in linux 2.0/2.2 tcp/ip
+    <youpi> oh
+    <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
+
+
+# Reimplementation, [[!GNU_Savannah_task 5469]]
+
+## IRC, freenode, #hurd, 2013-04-03
+
+[[!tag open_issue_hurd]]
+
+    <youpi> I was thinking about just using liblwip this afternoon, btw
+    <braunr> what is it ?
+    <braunr> hm, why not
+    <braunr> i would still prefer using code from netbsd
+    <braunr> especially now with the rump kernel project making it even easier
+    <youpi> well, whatever is easy to maintain up to date actually
+    <braunr> netbsd's focus on general portability normally makes it easy to
+      maintain
+    <braunr> the author of the rump project was able to make netbsd code run in
+      browsers :)
+    <braunr> and he actually showed clients using the networking stack on
+      windows, remotely (not in the same process)
+    <braunr> so that's very close to what we want
+    <youpi> indeed
+    <youpi> though liblwip is exactly the same portability focus :)
+    <braunr> apparently, for embedded systems
+    <youpi> but bsd's code is probably better
+    <youpi> yes
+    <braunr> i think so, more general purpose, larger user base
+    <youpi> I used it for the stubdomains in Xen
+    <youpi> (it = lwip)
+    <braunr> ok
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 79e8f05b..81826e00 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -147,3 +147,17 @@ Indeed, IPv6 now works properly, and the very machine hosting this wiki
     <youpi> I don't remember its url
     <braunr> git://git.kernel.org/pub/scm/linux/kernel/git/tglx/history.git
     <braunr> might be even older
+
+
+## IRC, freenode, #hurd, 2013-04-01
+
+    <congzhan`> hi, the ipv6 route works or not?
+    <congzhan`> I can use ipv6 to connect vms, but the vm can't access other
+      host except the router
+    <congzhan`> the ipv6 route -G seems not work for me, anyone make it work?
+    <youpi> I'm using SLAAC
+    <congzhan`> youpi: you mean static config not work?
+    <youpi> I mean automatic config does work
+    <youpi> I don't use static config myself
+    <congzhang> youpi: My ipv6 works now, just because not fully enable ipv6
+      forwarding and firewall, thank you:)
diff --git a/hurd/translator/tarfs.mdwn b/hurd/translator/tarfs.mdwn
index 4cc5f57a..3eb7b1ed 100644
--- a/hurd/translator/tarfs.mdwn
+++ b/hurd/translator/tarfs.mdwn
@@ -20,6 +20,21 @@ Works fine on most cases, occasional corruptions when writing using bzip2/gzip
 stores.
 
 
+## IRC, freenode, #hurd, 2013-03-16
+
+[[!tag open_issue_hurd]]
+
+    <pinotree> hm is tarfs working? its simple test suite fails here
+      (translator dies with gz and bz2 compression)
+    <braunr> no idea
+    <braunr> have you tried without compression ?
+    <pinotree> that succeeds
+    <braunr> it might rely on storeio for compression
+    <pinotree> no, it does gz/bz2 on its own
+    <pinotree> but it uses libstore for i/o of the file
+    <braunr> ok
+
+
 # Source
 
 [[source_repositories/incubator]], tarfs/master