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

36 files changed, 3900 insertions, 117 deletions

diff --git a/hurd/coding_style.mdwn b/hurd/coding_style.mdwn
new file mode 100644
index 00000000..cc1e3cf3
--- /dev/null
+++ b/hurd/coding_style.mdwn
@@ -0,0 +1,59 @@
+[[!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_documentation]]
+
+Some coding style comments that are specific to Hurd systems.
+
+[[!toc]]
+
+
+# Freeing Port Rights
+
+## IRC, freenode, #hurd, 2013-07-01
+
+    <teythoon> do I have to explicitly free ports in a short lived process like
+      mount?
+    <pinotree> better take the habit of doing that anyway
+    <teythoon> how do I recognize that I have to free something? mig spec?
+    <braunr> i'd say no
+    <braunr> mig does it for you
+    <braunr> gnumach reference manual
+    <teythoon> not memory, like port rights
+    <braunr> but no, really, for short lived processes it's ok
+    <braunr> yes, port rights
+    <braunr> like memory, you don't free stuff in short lived processes :p
+    <braunr> mach does it correctly when the task is destroyed
+    <braunr> but there are two use cases for rights
+    <braunr> those you create manually
+    <braunr> and those mig creates for its own purpose
+    <braunr> ignore those used by mig, they matter only in very specific parts
+      of glibc and other very low level stuff
+    <braunr> teythoon: keep in mind that there are two flavours of resources
+      with port rights
+    <teythoon> but how do I *know* from looking at say fs.defs that I have to
+      free anything I get?
+    <braunr> rights themselves, and the user reference count per right
+    <braunr> eh, that's complicated
+    <braunr> in a complete RPC call, you must watch two things usually
+    <braunr> out of line memory
+    <braunr> and right references
+    <braunr> except otherwise mentioned, you don't have to free anything
+    <braunr> freeing passed memory should be obvious (e.g. "out" keyword on a
+      memory range)
+    <braunr> for right references, it's less obvious
+    <braunr> refer to the mach server writing guide i guess
+    <teythoon> what does the dealloc qualifier do in mig defs?
+    <braunr> basically, send rights can be created from a receive right
+      (make_send), or another send right (copy_send)
+    <braunr> it tells mig which function to call once an RPC has returned
+    <braunr> all this is described in the mach server writing guide
+    <braunr> and it's tricky
+    <braunr> quite error-prone so check with portinfo
diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn
index f887d826..0022ec23 100644
--- a/hurd/console/discussion.mdwn
+++ b/hurd/console/discussion.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
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_documentation]]
 
+[[!toc]]
+
 
 # IRC, OFTC, #debian-hurd, 2012-09-24
 
@@ -40,3 +42,9 @@ License|/fdl]]."]]"""]]
       hacking?
     <allesa> to fix that is…
     <youpi> some hacking yes
+
+
+# IRC, freenode, #hurd, 2013-07-10
+
+    <pinotree> http://xkbcommon.org/ ‘¡û sounds interesting for our console
+      translator
diff --git a/hurd/debugging.mdwn b/hurd/debugging.mdwn
index f4b5eba5..ae9b7bef 100644
--- a/hurd/debugging.mdwn
+++ b/hurd/debugging.mdwn
@@ -26,3 +26,30 @@ License|/fdl]]."]]"""]]
   * [[glibc]]
   * [[translator]]s
   * [[trap_in_the_kernel]]
+
+
+# IRC, freenode, #hurd, 2013-06-30
+
+    <hacklu> braunr: I don't understand your question totally, but I want to
+      know how do you do this inspecting?  <braunr> i have a small test program
+      that creates a thread, and inspect its state before any thread dies
+    <braunr> i use portinfo
+    <braunr> and rpctrace
+    <braunr> (there is also vminfo but you're not likely to need it for what
+      you're doing right now)
+    <hacklu> I have used rpctrace before, but portinfo, I will try it.
+    <hacklu> is portinfo show a process's all port use log?
+    <braunr> not log
+    <braunr> current state
+    <hacklu> dump the port name space?
+    <braunr> yes
+    <hacklu> I found some names are not  continuous. how this come out?
+    <braunr> continuous ?
+    <hacklu> 101:send  103:send
+    <hacklu> missing 102
+    <braunr> some are freed
+    <braunr> a lot actually
+    <braunr> every RPC needs a reply port
+    <braunr> a temporary receive right to get replies from servers
+    <hacklu> so we can reuse the name which are freed before
+    <braunr> of course
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index a5c1a6e9..d62a4387 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -16,6 +16,17 @@ doing.
 See `rpctrace --help` about how to use it.
 
 
+# IRC, freenode, #hurd, 2013-07-29
+
+    <teythoon> about rpctrace, it poses as the kernel for its children, parses
+      and relays any messages sent over the childrens message port, right?
+    <braunr> teythoon: rpctrace doesn't "poses as the kernel"
+    <braunr> well, it's close enough
+    <teythoon> but it intercepts messages send by its children by handing them
+      a message port different from the one provided by the kernel, doesn't it?
+    <braunr> yes
+
+
 # Issues and Patches
 
 [[!tag open_issue_hurd]]
@@ -182,6 +193,38 @@ See `rpctrace --help` about how to use it.
 
             <youpi> uhu, there's a TODO just above that assertion :)
 
+* IRC, freenode, #hurd, 2013-07-05
+
+        <pinotree> wish: make rpctrace decode the results of io_stat rpcs
+
+* IRC, freenode, #hurd, 2013-07-29
+
+    <teythoon> imho rpctrace is kind of a mess right now :-/ we should move the
+      parsing code to a library
+    <teythoon> that would also be useful for valgrind, it should have to do
+      basically the same
+
+* IRC, freenode, #hurd, 2013-07-29
+
+    <teythoon> and I tried to rpctrace a subhurd, but rpctrace died on a
+      assertion failure, some msg had an unexpected type or something
+    <braunr> rpctrace dies on select
+    <braunr> and guess what, the boot tool does call select on the console it
+      emulates
+    <teythoon> that's a shame, that'd be really useful for me
+    <braunr> it might not be hard to fix
+    <braunr> but i've never looked into it :/
+    <braunr> i only saw that rpctrace expects the common RPC message types
+    <braunr> and select is all but a common RPC
+    <braunr> so the type of the messages involved is slightly different
+    <braunr> and the assertion chokes on that
+    <teythoon> rpctrace.c is huge and hand written, it'd be nice if the parser
+      was created from the procedure definitions
+    <teythoon> and thinking of that, mig does exactly that, one would only need
+      some glue code
+    <braunr> select is partially hand written
+    <braunr> but it's a special case so that's ok
+
 
 # See Also
 
diff --git a/hurd/libfuse.mdwn b/hurd/libfuse.mdwn
index 45ff97ec..78e96022 100644
--- a/hurd/libfuse.mdwn
+++ b/hurd/libfuse.mdwn
@@ -29,6 +29,26 @@ etc.
 * File I/O is quite slow.
 
 
+## IRC, freenode, #hurd, 2013-05-31
+
+    <zacts> well the reason I'm asking, is I'm wonder about the eventual
+      possibility of zfs on hurd
+    <pinotree> no, zfs surely not
+    <zacts> *wondering
+    <zacts> pinotree: would that be because of license incompatabilities, or
+      technical reasons?
+    <pinotree> the latter
+    <taylanub> It's just a matter of someone sitting down and implementing it
+      though, not ?
+    <pinotree> possibly
+    <braunr> zacts: the main problem seems to be the interactions between the
+      fuse file system and virtual memory (including caching)
+    <braunr> something the hurd doesn't excel at
+    <braunr> it *may* be possible to find existing userspace implementations
+      that don't use the system cache (e.g. implement their own)
+    <braunr> and they could almost readily use our libfuse version
+
+
 # Source
 
 [[source_repositories/incubator]], libfuse/master.
diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn
index 8eac39fe..b2e7f7a9 100644
--- a/hurd/libstore.mdwn
+++ b/hurd/libstore.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2013 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -6,8 +6,8 @@ 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]]."]]"""]]
 
 `libstore` is used to provide a generic interface to access data (read/write)
 on backing stores.
@@ -15,6 +15,8 @@ on backing stores.
 It more than just a thin layer between [[GNU Mach|microkernel/mach/gnumach]]
 devices (`hd0` for example) and the device node below `/dev/`...
 
+[[!toc]]
+
 
 # Available Stores
 
@@ -34,3 +36,32 @@ can be found.
 pages="hurd/libstore/examples/* and !*/discussion"
 show=0
 feeds=no]]
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-07-29
+
+[[!tag open_issue_documentation open_issue_hurd]]
+
+    <teythoon> and I read hammys paper about mobile code, is it true that the
+      store code is loaded into the client? who is the server and who is the
+      client in this context?
+    <braunr> teythoon: "store code" ?
+    <teythoon> libstore
+    <braunr> the hurd libstore ?
+    <teythoon> yes
+    <braunr> hum, what paper ?
+    <teythoon> braunr:
+      http://users.student.lth.se/cs07fh9/2009-hammar-hurd-mobility.pdf
+    <braunr> how nice
+    <tschwinge> braunr: http://www.gnu.org/software/hurd/news/2010-01-31.html
+    <teythoon> it raises an important point btw, the authentication done by
+      processes on the Hurd is one sided, only the client authenticates at the
+      server
+    <braunr> yes
+    <tschwinge> It'S also mentioned in
+      http://www.gnu.org/software/hurd/hurd/documentation.html -- but of
+      course, any results he got from his work really should be integrated more
+      properly into the existing body of documents.
+    <tschwinge> As with so many other documents/discussions/etc.  ;-|
diff --git a/hurd/libstore/part.mdwn b/hurd/libstore/part.mdwn
index 5260d05d..29ef9072 100644
--- a/hurd/libstore/part.mdwn
+++ b/hurd/libstore/part.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2012 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
@@ -28,6 +29,132 @@ A similar problem is described in
 [[community/gsoc/project_ideas/unionfs_boot]], and needs to be implemented.
 
 
-# TODO
+# Open Issues
 
-How to use, etc.
+## Documentation
+
+[[!tag open_issue_documentation]]
+
+## [[open_issues/hurd_build_without_parted]]
+
+## IRC, freenode, #hurd. 2013-09-21
+
+    <phcoder> Hello, guys. Is there a way to know where partition starts on
+      hurd. E.g. given hd0s1 get "2048 sectors"
+    <youpi> yes, it's the storeinfo RPC
+    <youpi> let me find you a pointer
+    <phcoder> in GRUB 2 files for determining device relations are a mess of
+      #if's. I try to split it into logical files and make common logic
+      uniform. Current Hurd's logic is completely different and, actually,
+      wrong. Same logic is used by Mac OS X part ...
+    <youpi> phcoder: Mmm, I guess you never got the userland-part.patch
+      upstream
+    <youpi> ah, yes ,you did
+    <youpi> I mean the find_hurd_root_device function
+    <youpi> grub was previously using file_get_storage_info
+    <phcoder> youpi: find_hurd_root_Device/file_get_storage info is about
+      translating / -> /dev/hd0s1. Current problem is in step hd0s1 ->
+      hd0,msdos1
+    <youpi> yes, but iirc file_get_storage_info might work for hd0s1 itself
+    <phcoder> I see, let me try this
+    <phcoder> youpi: file_get_storage gives offset=0 size=partition size
+    <youpi> (file_get_storage) damn
+    <phcoder> and name=hd0s1
+    <youpi> ah, that might be because we're still using in-kernel partition
+      table, instead of the parted partition table
+    <phcoder> looks like file_get_storage would be useful to get block size
+      though
+    <phcoder> youpi: is parted already used in some cases? Any reliable way to
+      check for it? Any way to access kernel partition map? Ioctl? RPC to
+      kernel?
+    <youpi> the parted table is only enabled in the debian installer for
+      now. You can set up one for yourself by running e.g. settrans -c
+      /tmp/myhd0s1 /hurd/storeio -T typed part:1:device:hd0
+    <youpi> I don't think there is any ioctl/RPC to get the kernel partition
+      table
+    <phcoder> youpi: is it using Linux partition code with some glue?
+    <youpi> phcoder: the kernel partition table, yes
+    <phcoder> youpi: that's bad. it's probably one of the least consistent
+      numbering schemes. It would imply that it only worked because only
+      simplest cases were ever tested
+    <youpi> I know
+    <youpi> that's why we want to migrate to the parted-based partition table
+      support
+    <youpi> (which also brings us much better support than the old linux2.0
+      code :) )
+    <phcoder> youpi: I've looked into code and must say that I dislike what I
+      see: partitions handled in ide/ahci/sd/...
+    <youpi> phcoder: which code?
+    <phcoder> youpi: gnumach
+    <youpi> sure, that's not what we want in the end
+    <phcoder> grep -r start_sect
+    <youpi> it's just the legacy linux way of doing partition support
+    <phcoder> Well Linux at least gives a meaningful ioctl
+    <phcoder> couldn't find any hint of it in gnumach
+    <youpi> we didn't bother to add one since the parted way is supposed to be
+      what we have in the end
+    <phcoder> youpi: I can't make our code follow sth that might be the case in
+      the future
+    <youpi> why not?
+    <youpi> that's the way we will go
+    <youpi> it's not just hypothetic
+    <youpi> we just can't continue maintaining disk drivers in the kernel
+    <youpi> so it won't be in the kernel
+    <phcoder> youpi: if I do then GRUB won't work on current GNU/Hurd anymore
+    <youpi> can't you also keep the old code?
+    <youpi> as a fallback when the proper way does not work (yet)
+    <phcoder> More hairs... :(
+    <phcoder> How do I check for it? offset == 0 isn't proper as partitions may
+      start at 0
+    <phcoder> but checking than name still refers to partition is probably the
+      right way
+    <youpi> I don't see what you mean
+    <youpi> (about name)
+    <phcoder> youpi: I mean that we need a way to know that current code is
+      used and not future parted-based code
+    <youpi> phcoder: I understand that for the offset ==0 thing
+    <youpi> but I didn't understand the phrase you wrote just after that
+    <phcoder> youpi: file_get_storage gives back a name. If this name is the
+      same as the partition we requested in the first place then it's current
+      code
+    <youpi> ah, ok
+    <youpi> yes, if the name is the same, it means it's not actually a
+      partition
+    <phcoder> youpi: current gnumach code makes fake devices out of partitions
+    <youpi> yes
+    <phcoder> youpi: with settrans command you told, I get num_ints = 0
+    <youpi> phcoder: odd, I do get information, e.g.:
+    <youpi> hurd:/tmp# settrans -c /tmp/mysd0s1 /hurd/storeio  -T typed
+      part:1:device:sd0
+    <youpi> hurd:/tmp# storeinfo mysd0s1
+    <youpi> device (0x200): sd0: 512: 83905: 42959360: 63+83905
+    <phcoder> storeinfo: myhd0s1: Operation not supported
+    <youpi> do you actually have an hd0 device?
+    <phcoder> yes
+    <phcoder> youpi: I typed parted instead of part
+    <phcoder> Now it works
+    <youpi> good :)
+    <phcoder> youpi: what is expected timeline on migration to part interface?
+    <youpi> there's no real timeline
+    <youpi> like everything, it'll happen when somebody actually looks at how
+      to achieve it
+    <youpi> perhaps it'll be easy, perhaps not. IIRC there is still an issue
+      with the swapper
+    <phcoder> youpi: sounds like we're stuck will fallback code for at least
+      couple of years
+    <youpi> possibly, entirely depends on people taking the task
+    <youpi> if that becomes really pressing at some point, I'll have to do it,
+      but of course, I can not magically do everything in a glimpse
+    <phcoder> youpi: it's not pressing but just be aware that unusual
+      partitioning is likely to fail. Probably not huge issue. As to its place
+      in our code it's not ideal but it's not the only case of suboptimal
+      construction for specific systems (what we had to do because of Linux
+      caching is terrifying). I'm not going to make hurd code a scapegot of
+      more generic problem
+    <phcoder> youpi: and since we very rarely drop support this code is
+      probably stuck for good
+    <youpi> as long as it's not used whenever we get to move to parted-based
+      partitioning, it's not too bad
+    <phcoder> youpi: and Mac OS X/Darwin case is even worse. Apparently they
+      deprecated their *BSD functions (which probably don't work since they
+      don't use BSD labels) without giving any replacement.
diff --git a/hurd/running.mdwn b/hurd/running.mdwn
index f0cb0809..b3caf21a 100644
--- a/hurd/running.mdwn
+++ b/hurd/running.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -17,7 +17,7 @@ There are several different ways to run a GNU/Hurd system:
 * [[microkernel/mach/gnumach/ports/Xen]] - In Xen
 * [[Live_CD]]
 * [[QEMU]] - In QEMU
-* [[openstack]] - In openstack
+* [[cloud]] - In the "cloud": OpenStack
 * [[chroots|chroot]] need a couple of tricks to work properly.
 * [[VirtualBox]] - In VirtualBox
 * [[vmware]] (**non-free!**)
diff --git a/hurd/running/cloud.mdwn b/hurd/running/cloud.mdwn
new file mode 100644
index 00000000..b063fd7b
--- /dev/null
+++ b/hurd/running/cloud.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]]."]]"""]]
+
+# [[!wikipedia OpenStack]]
+
+It is possible to run the Hurd as a KVM-based OpenStack cloud instance.
+
+[[For the time being|open_issues/virtio]], you'll have to avoid using virtio
+drivers, and use emulated hardware instead:
+
+    $ glance image-create --property hw_disk_bus=ide --property hw_cdrom_bus=ide --property hw_vif_model=rtl8139 --disk-format raw  --container-format bare --name gnu-hurd --copy-from http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img
diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn
index afa46799..849ff382 100644
--- a/hurd/running/debian/dhcp.mdwn
+++ b/hurd/running/debian/dhcp.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
@@ -29,3 +30,97 @@ scripts, but has its own `/libexec/rc` script -- which integrates scripts from
   * [[!debbug 616290]]
 
   * [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]]
+
+  * [[!message-id desc="dhclient aborting with a stack smashing error"
+    "874ngfvwn4.fsf@kepler.schwinge.homeip.net"]]
+
+    IRC, freenode, #hurd, 2013-08-21:
+
+        <teythoon> yay, I fixed the path of the dhcp leases file...
+        <teythoon> ... and now dhclient dies of a buffer overflow
+        <teythoon> fortunately the fix is rather simple, anyone who cares about
+          the security of his box just has to stop using isc software
+        <teythoon> the code is full of stuff like char foo[100]; /* surely
+          that's enough */
+        <pinotree> note that our version of isc-dchp (the one in ports) is
+          older than the latest one available in unstable (which is still older
+          than the latest upstream releases)
+        <teythoon> so?
+        <pinotree> dunno, might have been fixed or not
+        <teythoon> ^^ yeah sure
+        <gnu_srs> A lot of software has these limitations and PATH_MAX,
+          MAXPATHLEN issues :(
+        <pinotree> having a limitation is not a problem per-se
+        <teythoon> no, only software written in c has these kind of problems
+        <pinotree> the problem is not checking whether the limits are hit
+        <teythoon> well, looking at the source of isc-dhcp my time is better
+          spent making another dhcp client work on hurd
+        <teythoon> also reading up on bug #616290 does make me want to avoid
+          touching it ever
+        <braunr> hehe
+        <gnu_srs> teythoon: somebody was offering an alternative to the isc
+          dhcpclient, but I think it was rejected by Samuel?
+        <teythoon> why would he do that?
+        <braunr> probably for compliance
+        <gnu_srs> He probably thought they would release a new version soon, is
+          4.3.0 out yet?
+        <teythoon> well, as soon as my fixes for ifupdown go in, dhclient will
+          start crashing
+        <teythoon> no, there is no new version released
+        <teythoon> no major one that is
+        <teythoon> 4.2.5 is out
+        <gnu_srs> can't you just increase the buffer size, where is the problem
+          exactly?
+        <teythoon> I have no idea
+        <gnu_srs> The Hurd patches are not in 4.2.5, they were promised for
+          4.3.0a1. 
+        <gnu_srs> Still the buffer overflow problem might be present in 4.2.5
+          if patched to build on Hurd.
+        <braunr> there, darnassus now has a fully featured git/gitweb service
+        <teythoon> :)
+        <teythoon> btw, I managed to reproduce the crash reliably
+        <teythoon> rm /var/lib/dhcp/*; dhclient -v /dev/eth0  ... *boom*
+        <teythoon> ditch the -v, everything works, and now that there is a
+          lease file, you can add the -v again and it works
+        <braunr> ew :)
+        <teythoon> and what has dhclient.c to say for its defense?
+        <teythoon> log_info("%s", "");
+        <teythoon> hm, not much :/
+
+    IRC, freenode, #hurd, 2013-08-22:
+
+        <teythoon> uh, the isc-dhcp situation is a huge pita, the source on
+          -ports does not compile anymore :/
+
+    IRC, freenode, #hurd, 2013-08-23:
+
+        <gnu_srs> teythoon: Was it the slash in the network interface names
+          that caused the buffer overflow in dhclient? 
+        <teythoon> gnu_srs: no, previously no dhcp leases file was written and
+          everything was fine
+        <pinotree> teythoon: did you really develop your patch against that old
+          version of ifupdown?
+        <teythoon> gnu_srs: now it is written, and for some reason dhclient
+          crashes *iff* -v is given *and* there is no previous lease file
+        <teythoon> pinotree: no, I did not. that was only reportbug including
+          information from my desktop machine without asking me
+        <teythoon> but when I first looked at ifupdown it was still a 6000
+          lines noweb file >,<
+        <teythoon> that was fun
+        <pinotree> which version is it against?
+        <teythoon> hg tip
+
+    IRC, freenode, #hurd, 2013-08-30:
+
+        <tschwinge> teythoon: I understand correctly that you found that
+          id:"874ngfvwn4.fsf@kepler.schwinge.homeip.net" in fact was really
+          "just" a buffer overflow in the dhclient code?
+        <teythoon> tschwinge: ah, most interesting, I didn't realize that you
+          stumbled across this as well
+        <teythoon> to be honest I don't know what's going on there, I only
+          observed what I wrote in my report
+        <teythoon> for me it started crashing once the lease file was actually
+          a valid path (i.e. not to a non-existing directory b/c of the slashes
+          in /dev/eth0)
+        <teythoon> I tried to rebuild the package served on debian-ports, but
+          that failed
diff --git a/hurd/running/openstack.mdwn b/hurd/running/openstack.mdwn
deleted file mode 100644
index af03583b..00000000
--- a/hurd/running/openstack.mdwn
+++ /dev/null
@@ -1,14 +0,0 @@
-[[!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
-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]]."]]"""]]
-
-One can tell openstack to avoid using virtio drivers, and use emulated hardware instead:
-
-    glance image-create --property hw_disk_bus=ide --property hw_cdrom_bus=ide --property hw_vif_model=rtl8139 --disk-format raw  --container-format bare --name gnu-hurd --copy-from http://people.debian.org/~sthibault/hurd-i386/debian-hurd.img
diff --git a/hurd/running/requirementsforlivecd.mdwn b/hurd/running/requirementsforlivecd.mdwn
deleted file mode 100644
index 858988d1..00000000
--- a/hurd/running/requirementsforlivecd.mdwn
+++ /dev/null
@@ -1,24 +0,0 @@
-[[!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]]."]]"""]]
-
-HERE STARTS YOUR NEW CONTENT -- remove everything from here on, including this
-line.
-
-By creating this page, you agree to assign copyright for your contribution to
-the Free Software Foundation, <http://www.fsf.org/>.  The Free Software
-Foundation promises to always use a free documentation license (as per our
-criteria of free documentation) when publishing your contribution.  We grant
-you back all your rights under copyright, including the rights to copy, modify,
-and redistribute your contributions.
-
-We're requiring these copyright assignments, so that we'll easily be able to
-include your contributions in official GNU documentation, such as the GNU Hurd
-Reference Manual, etc.  Send email to <hurd-maintainers@gnu.org> if there are
-questions.
diff --git a/hurd/subhurd.mdwn b/hurd/subhurd.mdwn
index af119af3..55927fdd 100644
--- a/hurd/subhurd.mdwn
+++ b/hurd/subhurd.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2011, 2013 Free Software
+Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -42,6 +42,22 @@ set up another Hurd on a different partition, without ever rebooting.  (You can
 run the `native-install` step from a chroot or already in a subhurd.)
 
 
+### IRC, freenode, #hurd, 2013-09-15
+
+    <gnu_srs> Never dared to try a subhurd, any link to the howto? 
+    <teythoon> gnu_srs: I followed
+      http://www.gnu.org/software/hurd/hurd/subhurd.html though using crosshurd
+      didn't work for me, I just used debootstrap
+    <teythoon> gnu_srs: and you need a separate filesystem translator (i.e. not
+      /) for that
+    <teythoon> the easiest way is to add another virtual disk to you qemu setup
+    <braunr> use the qemu image directly
+    <braunr> simplest way to set up a subhurd
+    <braunr> just change fstab from the host before the first boot to avoid
+      making the subhurd use the same hd0 drive as the host
+    <teythoon> braunr: nice idea :)
+
+
 ## Booting
 
 To boot the subhurd, you need a boot script.  For historical reasons, usually
@@ -86,7 +102,8 @@ it!
 practice [that doesn't work at the
 moment](http://savannah.gnu.org/bugs/?17341).)
 
-You can provide the subhurd with a network card by passing a -f option to `boot`.
+You can provide the subhurd with a network card by passing a `-f` option to
+`boot`.
 
 Now the subhurd should boot just like a normal Hurd started directly from GRUB,
 finally presenting a login prompt.  The `boot` program serves as proxy for the
@@ -120,6 +137,362 @@ look at the number of threads (e.g. using `ps -l`), as many servers have very
 characteristic thread counts.
 
 
+### IRC, freenode, #hurd, 2013-08-09
+
+    <teythoon> btw, is there a way to get dde-based networking into a subhurd?
+    <teythoon> the wiki instructions look like they're for the mach driver
+    <teythoon> and starting the dde translator inside the subhurd does not work
+      for me
+    <teythoon> that's probably a good thing though
+    <youpi> the netdde process will need privileged access to mach
+    <youpi> for hardware access
+    <braunr> you can't easily use netdde from a subhurd, unless with a
+      different nic
+    <braunr> i usually rebuild mach with in kernel devices so both the main and
+      subhurd can share on nic
+    <braunr> one*
+    <youpi> could a port to netdde perhaps forwarded to the subhurd?
+    <braunr> zengh da wrote the eth-multiplexer for that iirc
+    <youpi> it's a matter of making it appear as an eth0 device on the master
+      port aiui
+    <braunr> zheng*
+    <teythoon> yes, I looked at that
+    <teythoon> what is the master port?
+    <youpi> on a plain hurd system it's the port that privileged processes can
+      use to access mach devices
+    <youpi> in a subhurd, it's the same for the subhurd, to access some devices
+      that you choose to give access to
+    <braunr> its real name is the "device master port"
+    <teythoon> ah yes
+
+
+#### IRC, freenode, #hurd, 2013-08-10
+
+    <antrik> teythoon: use eth-multiplexer to use the NIC within a
+      subhurd. that's exactly what it was created for.
+    <antrik> I don't remember whether it's even possible to share a "raw"
+      netdde device... I don't think I ever tried that; and I don't remember
+      enough of the theory to tell whether it should be possible
+    <antrik> but I really don't see the reason to, when eth-multiplexer is
+      available
+    <antrik> (IMHO running an eth-multiplexer on top of netdde should be the
+      default setup in fact)
+    <antrik> as for actually passing on the device, that should be perfectly
+      possible with zhengda's modified subhurd... but I don't remember whether
+      that was ever merged upstream
+    <antrik> (you will definitely need that for using netdde in a subhurd,
+      regardless whether through eth-multiplexer or directly)
+
+
+#### IRC, freenode, #hurd, 2013-09-15
+
+    <teythoon> I wonder if we can modify the boot program so that it passes
+      ports from the mother hurd to the subhurd
+    <teythoon> so that we could pass in a port to the eth-multiplexer
+    <teythoon> or use like /hurd/remap as the root translator for the subhurd
+    <braunr> eth-multiplexer was created exactly for that iirc,
+    <braunr> so it's probably already done somewhere
+
+
+#### IRC, freenode, #hurd, 2013-09-16
+
+    <gnu_srs> braunr: regarding subhurd did you mean to install
+      sthibault/hurd-i386/debian-hurd.img.tar.gz
+    <gnu_srs> on a separate partition and booting using the instructions for
+      subhurds on the web.
+    <braunr> gnu_srs: yes
+    <braunr> be careful that the subhurd doesn't use the same partition as the
+      main hurd, that's all
+    <gnu_srs> what about changing fstab?
+    <braunr> 12:17 < braunr> be careful that the subhurd doesn't use the same
+      partition as the main hurd, that's all
+    <teythoon> gnu_srs: yes, you need to change the fstab
+    <teythoon> currently it is used for fscking stuff, so if it points to your
+      main partition it will cause severe corruption
+    <teythoon> gnu_srs: you also have to specify the right partition in the
+      servers.boot file
+    <gnu_srs> fstab of the subhurd image?
+    <teythoon> yes
+    <gnu_srs> how to unpack the .img file (just to be sure)?
+    <teythoon> gnu_srs: you don't need to, just use the img file as secondary
+      hard disk image
+    <gnu_srs> Then how should I be able to change fstab of the image?
+    <teythoon> boot your hurd box, mount the partition and change it
+    <gnu_srs> I missed something here: on my partition /my_chroot I have have
+      the file debian-hurd-20130504.img
+    <teythoon> gnu_srs: ah, you copied it to the partition, braunr meant to use
+      it as the secondary disk, e.g. qemu ... -hdb debian-hurd-20130504.img ...
+    <gnu_srs> That is the same as installing another cd image, where does the
+      subhurd come into play?
+    <teythoon> mount the partition on the secondary hd, fix the fstab there,
+      mount it r/o, get the servers.boot file from the wiki, modify it so that
+      it points to the right partition, execute boot servers.boot /dev/<your
+      partition>, probably /dev/hd1s1
+    <gnu_srs> BTW: unpacking was problematic: tar: debian-hurd-20130504.img:
+      Cannot seek to 2147696640 (2G limitations)
+    <teythoon> I wonder why you did this on your hurd system in the first
+      place...
+    <gnu_srs> I thought I could use that partition, /my_chroot as a chroot
+      place. So it won't work for subhurds?
+    <teythoon> well, there are several ways to setup a subhurd. one is to
+      already have a spare partition for that and use crosshurd or as I did
+      debootstrap to install a debian system there
+    <teythoon> braunr suggested an even easier way, download the .img file and
+      use it as secondary hard disk
+    <teythoon> you ended up doing kind of both
+    <gnu_srs> I tried once with debootstrap and that created a disaster...
+    <teythoon> how so?
+    <gnu_srs> The install errored out, and the whole filesystem (including /)
+      was left in a broken state. Maybe I tried 
+    <gnu_srs> that without using a separate partition. Don't remember any
+      longer. So you say it's safe now?
+    <teythoon> I used it successfully to setup my subhurd
+    <gnu_srs> and you have your subhurd in a separate partition, installed from
+      there too, as root?
+    <gnu_srs> the web page only mentions crosshurd, and that failed for you?
+    <teythoon> yes, having a separate partition is (currently) necessary to run
+      a subhurd
+    <teythoon> yes, I used debootstrap as root, afaics that is necessary
+    <teythoon> and yes, as I said the other day, I tried crosshurd first and it
+      failed
+    <teythoon> then again, I fail to see any reason to use crosshurd these days
+    <teythoon> it's only a wrapper around debootstrap anyway, using it with
+      --foreign and fixing up stuff later
+    <teythoon> one has more control over the process if one uses debootstrap
+      directly
+    <gnu_srs> I still don't dare to do it yet. I'll create another image using
+      netinst with a separate partition and try out first.
+    <gnu_srs> When installing a new image using netinst.iso (2013-06-30) and
+      rebooting /proc does not get mounted?
+    <teythoon> gnu_srs: is that a statement or a question?
+    <gnu_srs> A statement.
+    <teythoon> it's not customary to end statements with question marks ;)
+    <gnu_srs> s/mounted?/mounted, why?/
+    <teythoon> well, you seem to be the last person to perform such an
+      installation, so you are in the perfect position to answer this question.
+    <gnu_srs> cat /var/log/dmesg?
+    <gnu_srs> On other images I have: fsysopts /proc; /hurd/procfs
+      --clk-tck=100 --stat-mode=444 --fake-self=1
+    <youpi> gnu_srs: no, check the installation log
+    <youpi> gnu_srs: and what does showtrans say?
+    <gnu_srs> showtrans /proc; <empty>
+    <gnu_srs> which log file to look for?
+    <youpi> the installation log, somewhere in /var/log probably
+    <gnu_srs> I only find /proc in /var/log/installer/syslog, mainly printing
+      out errors not finding /proc/mounts
+    <youpi> iirc the /proc translator should be set during the hurd package
+      configuration
+    <youpi> you should probably look for that part in the log
+    <youpi> Setting up translators: /hurd/exec /hurd/proxy-defpager
+      /hurd/pflocal (+link) /hurd/pfinet (+link) (+link) /hurd/procfs -c
+      /hurd/password crash-kill crash-suspend crash-dump-core crash.
+    <youpi> that part
+    <gnu_srs>  debootstrap:  /hurd/procfs -c and in-target:  /hurd/procfs -c No
+      errors
+    <youpi> I don't understand what that means
+    <youpi> please explain in more details
+    <gnu_srs> see: http://paste.debian.net/41195/
+    <youpi> makes much more sense :)
+    <gnu_srs> Where is the 'Setting up translators' done? I cannot find
+      anything in /var/lib/dpkg/info/hurd* or /etc/init.d/...
+    <pinotree> /usr/lib/hurd/setup-translators, called in hurd.postinst
+    <gnu_srs> tks:)
+    <gnu_srs> Hi, when installing a new image with debootstrap to /chroot the
+      script boot/servers.boot is already there (as well as in /boot/ + grub)
+    <gnu_srs> Is it OK to use that file to boot the subhurd? 
+    <gnu_srs> using /boot/servers.boot or /chroot/boot/servers.boot (if the
+      /chroot partition is unmounted it cannot be used?)
+    <gnu_srs> and how to unmount /chroot: umount does not work?
+    <gnu_srs> braunr: I'm also trying to find out what's wrong with glibc, when
+      my subhurd is up and running 2.13-39 (if possible)
+    <gnu_srs> I know I should issue settrans command, but I'm not yet fluent in
+      translators.
+    <gnu_srs> sorry:-/
+    <gnu_srs> Now this, after a reboot: unknown code P 30 while trying to open
+      /dev/hd0s3 (/chroot)
+    <gnu_srs> Disk write protected: use the -n option to do a read-only check
+      of the device.
+    <gnu_srs> fsysopts /dev/&hd0s1 --writable: Operation not supported??
+    <gnu_srs> OK, I'm giving up for now, no subhurd:-( and a broken install.
+    <gnu_srs> Which terminal to use in rescue mode, TERM is not set,
+      dumb,mach,hurd does not work with nano?
+    <gnu_srs> e2fsck /dev/ho0s3; e2fsck: Unknown code P 2 while trying to open
+      /dev/ho0s3; Possibly non-existent device?
+    <gnu_srs> mke2fs /dev/hd0s3; /dev/hd0s3 is not a block special device.;
+      Proceed anyway? (y,n) n: What's going on (hd0s3 not mounted)??
+    <gnu_srs> anybody, help?
+    <gnu_srs> after removing and creating the partition again:mke2fs
+      /dev/hd0s3, <same>, mke2fs: Unknown code P 13 while trying to determine
+      filesystem size: What's going on?
+    <gnu_srs> Where to find the glibc-2.13 versions which used to be at
+      debian-ports?.
+    <gnu_srs> seems they can be found on snapshot.debian.org
+
+
+#### IRC, freenode, #hurd, 2013-09-17
+
+    <gnu_srs> teythoon: Installing subhurd via debootstrap on partition
+      /chroot fails miserably. Install hangs, and after reboot \rm -r
+      /chroot/* fails for dev and proc
+    <gnu_srs> Are there translators running there already? I have not
+      booted the subhurd. 
+    <gnu_srs> translators for hd0s3 (/chroot) are storeio and
+      ex2fs.static. Do I have to stop them to be able to clean out
+      /chroot?
+    <gnu_srs>  mount -v /chroot; settrans -a /chroot /hurd/ext2fs
+      /dev/hd0s3;
+    <gnu_srs> ext2fs: /dev/hd0s3: panic: main: device too small for
+      superblock (0 bytes);
+    <gnu_srs> mount: cannot start translator /hurd/ext2fs: Translator
+      died
+    <gnu_srs> Please, somebody!
+    <gnu_srs> don't ask to ask, just ask, right?
+    <braunr> we've already told you everything you need
+    <braunr> just get it right
+    <braunr> for example, i told you to be careful about fstab so that
+      the subhurd wouldn't use the main hurd partition
+    <braunr> but you managed to screw that
+    <braunr> good job
+    <gnu_srs> I installed the subhurd in a partition /chroot /dev/hd0s3
+      using debootstrap
+    <braunr> i don't know deboostrap, it may be broken, use the disk
+      image youpi maintains
+    <gnu_srs> ant the install screwed up with debootstrap
+    <gnu_srs> ok; then I cannot use a partition, but another disk in
+      kvm, e.g. hdb?
+    <braunr> gnu_srs: hd1
+    <gnu_srs> something is fishy with glibc, definitely, that's why I'm
+      trying to set up a subhurd to revert to 2.13-39
+    <gnu_srs> hi, when trying to boot a subhurd: /hurd/ext2fs.static:
+      hd0s3: Gratuitous error; bye
+    <braunr> gnu_srs: why hd0s3 ?
+    <braunr> it should be hd1s1
+    <gnu_srs> I'm still using a separate partition /my_chroot
+      /hd0s3. Will switch to hd1 next. teythoon?
+    <gnu_srs> the servers.boot script use absolute
+      paths:/hurd/ext2fs.static and /lib/ld.so.1 /hurd/exec, 
+    <gnu_srs> shouldn't they be relative to /my_chroot?
+    <braunr> no
+    <braunr> they're actually from your host
+    <gnu_srs> teythoon: please, how did you succeed to boot a subhurd
+      in a partition?
+    <gnu_srs> using debootstrap
+    <teythoon> gnu_srs: from my shell history:
+    <teythoon> : 1374672426:0;debootstrap sid /mnt
+      http://http.debian.net/debian/
+    <teythoon> : 1374673020:0;cp /etc/hosts /etc/resolv.conf /mnt/etc
+    <teythoon> : 1374673048:0;cp /etc/passwd /etc/shadow /mnt/etc
+    <braunr> teythoon: so it does work fine ?
+    <braunr> great
+    <teythoon> yes, why wouldn't it?
+    <teythoon> gnu_srs: I then remounted that partition r/o and used
+      the servers.boot file from the wiki to boot it
+    <teythoon> braunr: why wouldn't it? (you do mean the debootstrap
+      part, don't you?)
+    <braunr> teythoon: i don't know
+    <braunr> i've heard it wasn't maintained any more
+    <braunr> not being maintained is a good reason for something to
+      become unusable/untrustable with time
+    <teythoon> o_O it is at the heart of d-i, isn't it?
+    <teythoon> I actually do most Debian installations using
+      debootstrap directly
+    <braunr> ah
+    <braunr> ok :)
+    <braunr> teythoon: even hurd ones ?
+    <teythoon> braunr: well, just the subhurd installation, but that
+      went as expected
+    <braunr> good
+    <gnu_srs> Finally: I found the reason for Gratuitous error, I used
+      the /boot/servers.boot script, 
+    <gnu_srs> that being different to the one on the wiki:-/
+    <gnu_srs> Is it possible to copy files between a host hurd and
+      subhurd, what about access to eth0? 
+    <gnu_srs> Hi, when starting the subhurd I see some warnings/error:
+      http://paste.debian.net/41963/
+    <gnu_srs> 1) A spelling error execunable-> executable
+    <gnu_srs> 2) libports: invalid destination port
+    <gnu_srs> 3) mach-defpager: another already running
+    <pinotree> "execunable" is not a typo, but just "exec" and "unable
+      ..." without a space-type character
+    <gnu_srs> OK, sounds more plausible
+    <gnu_srs> Ah, the printouts are mixed, no bug
+    <gnu_srs> When setting up nework in the subhurd: /hurd/pfinet:
+      file_name_lookup /dev/eth0: Translator died
+    <gnu_srs> /hurd/pfinet: device_open(/dev/eth0): (os/device) no such
+      device
+    <gnu_srs> settrans: /hurd/pfinet: Translator died
+
+
+#### IRC, freenode, #hurd, 2013-09-18
+
+    <youpi> priority does not matter much
+    <youpi> memory manager is not really surprising, there's indeed already one
+    <youpi> what is actually the problem?
+    <gnu_srs> So these are merely warnings?
+    <youpi> gnu_srs: yes
+    <gnu_srs> Real problems are I cannot set up networking, e.g. wget ...:
+      Connecting to ... failed: Address family not supported by protocol.
+    <youpi> gnu_srs: did you give the subhurd a network card?
+    <gnu_srs> How?
+    <gnu_srs> and do I need to set up fstab, for now it's empty.
+    <gnu_srs> I just installed the base with dbootstrap
+    <youpi> gnu_srs: -f option of boot
+    <youpi> e2fsck will need fstab for sure
+    <youpi> otherwise it can't divine what should be checked
+    <gnu_srs> Why is the /boot/servers.boot different from the subhurd one on
+      the wiki? Is it used at all, I thought grub was in charge.
+    <youpi> it's not used at all
+    <gnu_srs> maybe better to put in the subhurd one there then, with a
+      comment?
+    <youpi> no, since /boot/servers.boot is supposed to be used for machine
+      boot
+    <youpi> not subhurd boot
+    <gnu_srs> what about putting a copy of the suhurd one there, with a
+      different name?
+    <youpi> probably a good idea, yes
+    <youpi> matter of making it happen
+    <gnu_srs> the wiki page on subhurd does not say how to set up networking,
+      only that you can do it.
+    <youpi> matter of adding the information
+    <youpi> I remember it's the -f option of boot
+    <youpi> make it work, and add the information for others
+    <gnu_srs> I could try, but don't know how to add a network card to the
+      subhurd, and e.g. how to set up swap
+    <youpi> see -f option
+    <gnu_srs> of boot?
+    <youpi> "gnu_srs: -f option of boot"
+    <youpi> if you could read what we write, that'd make things happen way
+      faster
+    <gnu_srs> yes I saw your comment above, it was just to be 100% sure:-D
+    <gnu_srs> device_file=/dev/eth0 or something else?
+    <gnu_srs> eth0 is used by the host already
+    <youpi> did you read boot --help ?
+    <youpi> iirc it's not a problem, both will receive all frames
+    <gnu_srs> yes I did
+    <youpi> then I don't see where you took device_file from
+    <youpi> at least in that form
+    <youpi> --device=device_name=device_file
+    <youpi> that means rather something like --device=foo=bar
+    <gnu_srs> so -f /dev/eth0 is correct usage then?
+    <youpi> didn't you see that in what I wrote, there was a "=" in there?
+    <gnu_srs> -f is the short option, --device is the long, I don't see the
+      need for = in the short option?
+    <youpi> in the long option there are *two* =
+    <gnu_srs> yes, but in the short no?
+    <youpi> why not?
+    <youpi> long -> short usually drops one =
+    <gnu_srs> to summarize: -f=/dev/eth0 or --device=eth_sub=/dev/eth0?
+    <youpi> why shouldn't there be a eth_sub in the short version?
+    <gnu_srs> 10:15:49) youpi: long -> short usually drops one =
+    <youpi> yes, it drops the =
+    <youpi> but  nothing else
+    <youpi> if the long option needs some information, the short needs it too?
+    <youpi> -?
+    <gnu_srs> correct now? -f eth_sub=/dev/eth0 or --device=eth_sub=/dev/eth0?
+    <youpi> yes
+    <gnu_srs> k!
+
+
 # Further Info
 
 Read about using a subhurd for [[debugging_purposes|debugging/subhurd]].
diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn
index 6e694677..fac93625 100644
--- a/hurd/subhurd/discussion.mdwn
+++ b/hurd/subhurd/discussion.mdwn
@@ -170,3 +170,13 @@ License|/fdl]]."]]"""]]
     <zacts> ah ok
     <braunr> in theory, subhurds can run without root privileges
     <braunr> (but there are currently a few things that prevent it)
+
+
+## IRC, freenode, #hurd, 2011-06-07
+
+    <zacts> would hurd jails be more powerful than FreeBSD jails? how so?
+    <braunr> not more powerful
+    <braunr> easier to develop
+    <braunr> safer
+    <braunr> perhaps more powerful too, but that entirely depends on the
+      features you want inside
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index d4eaf950..52cd09f7 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -90,17 +90,22 @@ The [[concept|concepts]] of translators creates its own problems, too:
 * [[hello]]
 * [[auth]]
 * [[exec]]
+* [[proc]]
 * [[pfinet]]
+* [[eth-filter]]
 * [[pflocal]]
 * [[hostmux]]
 * [[storeio]]
 * [[ext2fs]]
 * [[fatfs]]
+* [[ufs]]
 * [[magic]]
+* [[mtab]]
 * [[unionfs]]
 * [[nfs]]
 * [[symlink]]
 * [[firmlink]]
+* [[fifo]]
 * ...
 
 
@@ -112,6 +117,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
 * [[procfs]]
 * [[nsmux]]
 * [[netio]]
+* [[socketio]]
 * [[tarfs]]
 * [[gopherfs]]
 * [[smbfs]]
@@ -122,7 +128,7 @@ The [[concept|concepts]] of translators creates its own problems, too:
 *These Translators are available in the [hurdextras repository](http://savannah.nongnu.org/cvs/?group=hurdextras) but not yet described on this website. They are in varying stages of Development.*
 
 * [jfs](http://www.nongnu.org/hurdextras/#jfs)
-* [httpfs](http://www.nongnu.org/hurdextras/#httpfs)
+* [[httpfs]]
 * [memfs](http://www.nongnu.org/hurdextras/#memfs)
 * [notice](http://www.nongnu.org/hurdextras/#notice)
 * [pith](http://www.nongnu.org/hurdextras/#pith)
diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn
index d9e70ec2..7fd4832c 100644
--- a/hurd/translator/auth.mdwn
+++ b/hurd/translator/auth.mdwn
@@ -1,12 +1,19 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 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 *auth server* (or, *authentification server*).
+
+It is stated by `/hurd/init`.
+
+
+# Documentation
 
 [[*The_Authentication_Server*|documentation/auth]], the transcript of a talk
 about the details of the authentication mechanisms in the Hurd by Wolfgang
diff --git a/hurd/translator/eth-filter.mdwn b/hurd/translator/eth-filter.mdwn
index 36ef4217..b5dc8f8f 100644
--- a/hurd/translator/eth-filter.mdwn
+++ b/hurd/translator/eth-filter.mdwn
@@ -8,20 +8,45 @@ 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]]."]]"""]]
 
-`eth-filter` is a translator that implements a very simple stateless firewal.
+`eth-filter` is a translator that implements a very simple stateless firewall.
+
 
 # Source
 
 [[source_repositories/incubator]], dde
 
-# Usage:
+
+# Usage
 
 For instance, to drop any attempt to access port 22:
 
-    settrans -c /dev/eth0f /hurd/eth-filter -i /dev/eth0 -r "not port 22"
+    # settrans -c /dev/eth0f /hurd/eth-filter -i /dev/eth0 -r "not port 22"
+
+This creates a `/dev/eth0f` device, which is the filtered version of
+`/dev/eth0`.  One can then use `/dev/eth0f` instead of `/dev/eth0`:
+
+    # settrans /servers/socket/2 /hurd/pfinet -i /dev/eth0f [...]
+
+..., or run `dhclient /dev/eth0f`, or similar.
+
+See also Zheng Da's [[user/zhengda/howto]].
+
+
+# Open Issues
 
-This creates a /dev/eth0f device, which is the filtered version of /dev/eth0. One can then configure network by hand using /dev/eth0f instead of /dev/eth0:
+## IRC, freenode, #hurd, 2013-07-27
 
-    settrans /servers/socket/2 /hurd/pfinet -i /dev/eth0f ...
+[[!tag open_issue_hurd]]
 
-or run dhclient /dev/eth0f, etc.
+    <youpi> ok, so as usual we actually *already* have a firewall
+    <youpi> it's the eth-filter translator from zheng da
+    <youpi> it has just never been really pushed forward...
+    <teythoon> good news :)
+    <youpi> well, the bad news is that it probably doesn't support connection
+      tracking
+    <youpi> since it's just bpf
+    <youpi> using the libpcap syntax
+    <teythoon> well, a stateless fw should do for Debian/Hurds needs for now,
+      right?
+    <youpi> yes
+    <youpi> and it does work indeed
diff --git a/hurd/translator/examples.mdwn b/hurd/translator/examples.mdwn
index 867d4935..4947808e 100644
--- a/hurd/translator/examples.mdwn
+++ b/hurd/translator/examples.mdwn
@@ -16,7 +16,7 @@ or [hurd-extras](http://www.nongnu.org/hurdextras/).
 
     cvs -z3 -d:pserver:anonymous@cvs.savannah.nongnu.org:/sources/hurdextras co <modulename> 
 
-* httpfs translator 
+* [[httpfs]] translator
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
@@ -28,7 +28,7 @@ or
     $ cd tmp/
     $ ls -l      
 
-* ftpfs translator
+* [[ftpfs]] translator
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
@@ -67,13 +67,13 @@ This is not as fast as `tar czvf newfile.tar.gz all my files`, but at least it's
 
     $ settrans -fgca /servers/socket/2 /hurd/pfinet -i <interface> -a <ip address> -m <subnet mask> -g <gateway ip>
    
-* Console translator -- setting up virtual consoles  
+* [[Console]] translator -- setting up virtual consoles
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
     $ console -d vga -d pc_mouse -d pc_kbd -d generic_speaker /dev/vcs
    
-* iso9660fs translator --  'mounting' your cdrom 
+* [[iso9660fs]] translator --  'mounting' your cdrom
 
 <!-- Prevent ikiwiki / Markdown rendering bug.  -->
 
diff --git a/hurd/translator/exec.mdwn b/hurd/translator/exec.mdwn
index 54abba7e..1dc0ea26 100644
--- a/hurd/translator/exec.mdwn
+++ b/hurd/translator/exec.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2012 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -11,4 +12,9 @@ License|/fdl]]."]]"""]]
 The *exec* server, listening on `/servers/exec`, is responsible for
 preparing the execution of processes.
 
+
+# Open Issues
+
+  * [[open_issues/exec]].
+
   * [[open_issues/exec_memory_leaks]].
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 20faed5e..e2f6b044 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -179,6 +179,69 @@ small backend stores, like floppy devices.
 That would be a nice improvement, but only after writeback throttling is implemented.
 
 
+## Stripped vs. Unstripped `ext2fs.static`
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-17
+
+    <teythoon> I always had some trouble with dropping a rebuild ext2fs.static
+      into my test system and I never figured out why
+    <teythoon> I just followed a hunch and stripped the binary, and all of the
+      sudden it works
+    <teythoon> any ideas why?
+    <tschwinge> teythoon: I quick search found me:
+      <https://savannah.gnu.org/bugs/?8497> and
+      <http://news.gmane.org/find-root.php?message_id=%3c4090243E.2040605%40comcast.net%3e>.
+    <teythoon> tschwinge: ugh, thanks for the pointers ;)
+    <tschwinge> teythoon: They won't help too much I fear.  Anyway, good
+      intuition (or whatever) ;-) that you found this out.
+    <tschwinge> teythoon: Not exactly related to stripped/unstripped per se
+      (that is, debug information), but in the past we've had an issue about
+      relro (see binutils/glibc, <http://www.airs.com/blog/archives/189>),
+      where a variable (that erroneously happend to be in such a read-only
+      section, if I remember correct) was tried to be modified -- which worked
+      "sometimes": depending on where exactly it was located in the binary
+      (which shifted around a page
+    <tschwinge> boundary by stripped/unstripped), it'd segfault or not.  Burnt
+      several days on that before Samuel (IIRC) eventually figured it out.
+    <teythoon> tschwinge: well, thanks anyway ;)
+
+
+## Increased Memory Consumption
+
+### IRC, freenode, #hurd, 2013-09-18
+
+    <braunr> ext2fs is using a ginormous amount of memory on darnassus since i
+      last updated the hurd package :/
+    <braunr> i wonder if my ext2fs large store patches rework have introduced a
+      regression
+    <braunr> the order of magnitude here is around 1.5G virtual space :/
+    <braunr> it used to take up to 3 times less before that
+    <braunr> looks like my patches didn't make it into the latest hurd package
+    <braunr> teythoon: looks like there definitely is a new leak in ext2fs
+    <teythoon> :/
+    <braunr> memory only
+    <braunr> the number of ports looks stable relative to file system usage
+    <teythoon> braunr: I tested my patches on my development machine, it's up
+      for 14 days (yay libvirt :) and never encountered problems like this
+    <braunr> i've been building glibc to reach that state
+    <teythoon> hm, that's a heavy load indeed
+    <teythoon> could be the file name tracking stuff, I tried to make sure that
+      everything is freed, but I might have missed something
+    <braunr> teythoon: simply running htop run shows a slight, regular increase
+      in physical memory usage in ext2fs
+    <pinotree> old procfs stikes again? :)
+    <teythoon> braunr: I see that as well... curious...
+    <braunr> 16:46 < teythoon> could be the file name tracking stuff, I tried
+      to make sure that everything is freed, but I might have missed something
+    <braunr> how knows, maybe completely unrelated
+    <teythoon> the tracking patch isn't that big, I've gone over it twice today
+      and it still seems reasonable to me
+    <braunr> hm
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/fifo.mdwn b/hurd/translator/fifo.mdwn
new file mode 100644
index 00000000..857922fc
--- /dev/null
+++ b/hurd/translator/fifo.mdwn
@@ -0,0 +1,48 @@
+[[!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]]."]]"""]]
+
+The *fifo* translator implements named pipes (FIFOs).
+
+
+# Open Issues
+
+## Not Terminating
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-28
+
+    <gg0> seems fifos started dying, as they should. am i wrong?
+    <gg0> ( http://bugs.debian.org/629184 )
+    <azeem> so you're saying the bug should be closed?
+    <azeem> best to comment on the bug then
+    <gg0> i didn't hear anyone working on it, so i'm a bit surprised
+    <azeem> could be due to lower-level fixes to glibc or so
+    <gg0> and given often(:|) i'm wrong, i was asking
+    <pinotree> in two years there have been various changes in glibc and hurd
+    <pinotree> (for example the switch to pthreads)
+    <gg0> yeah seems fixed. mknod'ing one then removing it, doesn't leave any
+      process around
+    <gg0> cool
+    <azeem> then please follow-up on the bug and/or close it
+    <gg0> sure
+    <gg0> the pleasure of closing it/them is yours
+    <gg0> great job, whatever you did :)
+
+
+### IRC, OFTC, #debian-hurd, 2013-07-29
+
+    * gg0 wonders if it can close savannah one as
+        wellhttps://savannah.gnu.org/bugs/?17128
+    <pochu> gg0: wdym?
+    <pochu> gg0: got an example?
+    <gg0> http://bugs.debian.org/629184
+    <gg0> i didn't close it myself
diff --git a/hurd/translator/firmlink.mdwn b/hurd/translator/firmlink.mdwn
index 038879db..b53396b0 100644
--- a/hurd/translator/firmlink.mdwn
+++ b/hurd/translator/firmlink.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
@@ -20,3 +20,15 @@ License|/fdl]]."]]"""]]
     <braunr> infinity0: firmlinks
     <infinity0> ah thanks i'll look that up
     <kilobug> braunr: oh, true, I forgot about that one
+
+
+# Open Issues
+
+  * [[!GNU_Savannah_bug 29809]]
+
+  * IRC, freenode, #hurd, 2013-07-07
+
+        <youpi> ok, found the firmlink-mv issue
+        <youpi> will commit that
+        <pinotree> \o/
+        <youpi> (bit of mach_print in translators, took just a few hours)
diff --git a/hurd/translator/hostmux.mdwn b/hurd/translator/hostmux.mdwn
index 5fab2dc5..ef16505b 100644
--- a/hurd/translator/hostmux.mdwn
+++ b/hurd/translator/hostmux.mdwn
@@ -29,3 +29,18 @@ When <code>**/ftp**</code> is accessed, the first directory is interpreted as ho
 You can see the new created translator in the process list: <code>**ps ax | grep ftpsfs**</code> . You shoud see <code>**/hurd/ftpfs / ftp.yourhost.com**</code> .
 
 -- [[Main/PatrickStrasser]] - 13 Jul 2004
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-09-21
+
+[[!tag open_issue_hurd]]
+
+    <jproulx> ls /http://<ip>:<port>/
+    <jproulx> the image came with a global translator though I see it doesn't
+      grokk the alternate port notation.
+    <youpi> oh right
+    <jproulx> I shall return to the fine documentation
+    <youpi> it's a hostmux, it doesn't understand ports
+    <youpi> damn, one thus can't url plain urls with that scheme
diff --git a/hurd/translator/httpfs.mdwn b/hurd/translator/httpfs.mdwn
new file mode 100644
index 00000000..dc4a62f7
--- /dev/null
+++ b/hurd/translator/httpfs.mdwn
@@ -0,0 +1,100 @@
+[[!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]]."]]"""]]
+
+`httpfs` is a virtual filesystem allowing you to access web pages and files.
+
+
+# Source
+
+<http://www.nongnu.org/hurdextras/#httpfs>
+
+
+# Documentation
+
+## IRC, freenode, #hurd, 2013-09-03
+
+[[!tag open_issue_documentation]]
+
+    <congzhang> hi, why I can't cd to /http:/richtlijn.be/~larstiq/hurd/ to do
+    <congzhang> 	    grep?
+    <pinotree> this is not ftp
+    <congzhang> it works for other file
+    <pinotree> ?
+    <congzhang> I can't cd to ~larstiq, I don't know why
+    <pinotree> http is not a filesystem protocol
+    <pinotree> while httpfs could try in representing it as such, it is not
+      something reliable
+    <congzhang> ok, it's not reliable
+    <congzhang> I expect it can expose dir like browser
+    <congzhang> so, the translator just know href from home page, and one by
+      one
+    <pinotree> uh?
+    <congzhang> if ...:80/a/b/c.png exits, but not has a href in homepage, so I
+      can't cd to a, right?
+    <pinotree> you are looking things from the wrong point of view
+    <pinotree> a web server can do anything with URLs, including redirecting,
+      URL rewriting and whatever else
+    <congzhang> so, how to understand httpfs's idea?
+    <congzhang> how httpfs list dir?
+    <pinotree> check its code
+    <congzhang> en, no need it's not reliable
+    <congzhang> it's not work, it's enough
+    <congzhang> I have an idea, for the file system, we explore dir level by
+      level, but for http, we change full path one 
+    <congzhang> once time
+    <congzhang> maybe can allow user to cd any directory, and just mark as some
+      special color to make user know the translator was not sure, file exist
+      or not
+    <congzhang> once the file exits, mark all the parent directory as normal
+      color?
+    <rekado> congzhang: you can find more info about httpfs here:
+      http://nongnu.org/hurdextras/
+    <pinotree> congzhang: you're still looking at http from the wrong point of
+      view
+    <pinotree> there are no directories nor files
+    <pinotree> you start a request for a URL, and you get some content back (in
+      case there's no error)
+    <congzhang> you mean httpfs just for kidding?
+    <pinotree> that the content is a web page listing a directory on the
+      filesystem of the web server machine, or a file sent back via the
+      connection, or a complex web page, it's the same
+    <rekado> congzhang: you can only get a list of files if the web server
+      responds with an index of files
+    <pinotree> "files"
+    <rekado> The readme explains how httpfs does its thing:
+      http://cvs.savannah.gnu.org/viewvc/*checkout*/httpfs/README?root=hurdextras
+    <congzhang> if I can't cd to /http:/host/a/b how to get
+      /http:/host/a/b/c.html, even the file exist?
+    <pinotree> you don't cd in http
+    <pinotree> cd is for changing directory, which does not apply to a protocol
+      like http which is not fs-oriented
+    <congzhang> yes, I agree with you, http was not fs-oriented
+    <congzhang> so httpfs was not so useful
+    <rekado> You can access the document directly, though, can't you?
+    <congzhang> rekado: I try once more
+    <congzhang> I can't
+    <congzhang> so, the httpfs need some extend, http protocol was not fs
+      oriented, so need some extend to make it work with file system
+    <pinotree> http is not designed for file system usage, so extending it is
+      useless
+    <congzhang> or, httpfs was not so useful
+    <pinotree> there are many other protocols for file systems
+    <congzhang> I don't think so
+    <pinotree> i do
+    <congzhang> if we can't make it more useful, remove it from hurd rep, or
+      extend it more useful
+    <congzhang> add some more rule, to make it work with file system
+    <pinotree> no
+    <congzhang> some paradox in it
+    <pinotree> which paradox?
+    <congzhang> for http vs file system
+    <pinotree> ???
+    <congzhang> tree oriented and  star topology oriented?
+    <pinotree> you don't make any sense
diff --git a/hurd/translator/mtab.mdwn b/hurd/translator/mtab.mdwn
new file mode 100644
index 00000000..8eca15b9
--- /dev/null
+++ b/hurd/translator/mtab.mdwn
@@ -0,0 +1,23 @@
+[[!meta copyright="Copyright © 2008, 2009, 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]]."]]"""]]
+
+In traditional monolithic system, the kernel keeps track of all mounts; the
+information is available through `/proc/mounts` (on Linux at least), and in a
+very similar form in `/etc/mtab`.
+
+The Hurd on the other hand has a totally
+[[decentralized_file_system|hurd/virtual_file_system]].  There is no single
+entity involved in all mounts.  Rather, only the parent file system to which a
+mountpoint ([[hurd/translator]]) is attached is involved.  As a result, there
+is no central place keeping track of mounts.
+
+The `mtab` translator has been implemented; see the [[discussion]] subpage for
+design considerations.
diff --git a/hurd/translator/mtab/discussion.mdwn b/hurd/translator/mtab/discussion.mdwn
new file mode 100644
index 00000000..0734e1e6
--- /dev/null
+++ b/hurd/translator/mtab/discussion.mdwn
@@ -0,0 +1,2122 @@
+[[!meta copyright="Copyright © 2008, 2009, 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_documentation]] The following text needs to be updated.
+
+# Original Project Description
+
+As a consequence, there is currently no easy way to obtain a listing of all
+mounted file systems. This also means that commands like `df` can only work on
+explicitly specified mountpoints, instead of displaying the usual listing.
+
+One possible solution to this would be for the translator startup mechanism to
+update the `mtab` on any `mount`/`unmount`, like in traditional systems.
+However, there are some problems with this approach.  Most notably: what to do
+with passive translators, i.e., translators that are not presently running, but
+set up to be started automatically whenever the node is accessed?  Probably
+these should be counted among the mounted filesystems; but how to handle the
+`mtab` updates for a translator that is not started yet?  Generally, being
+centralized and event-based, this is a pretty inelegant, non-hurdish solution.
+
+A more promising approach is to have `mtab` exported by a special translator,
+which gathers the necessary information on demand.  This could work by
+traversing the tree of translators, asking each one for mount points attached
+to it.  (Theoretically, it could also be done by just traversing *all* nodes,
+checking each one for attached translators.  That would be very inefficient,
+though.  Thus a special interface is probably required, that allows asking a
+translator to list mount points only.)
+
+There are also some other issues to keep in mind.  Traversing arbitrary
+translators set by other users can be quite dangerous -- and it's probably not
+very interesting anyways what private filesystems some other user has mounted.
+But what about the global `/etc/mtab`?  Should it list only root-owned
+filesystems?  Or should it create different listings depending on what user
+contacts it?...
+
+That leads to a more generic question: which translators should be actually
+listed?  There are different kinds of translators: ranging from traditional
+filesystems ([[disks|hurd/libdiskfs]] and other actual
+[[stores|hurd/translator/storeio]]), but also purely virtual filesystems like
+[[hurd/translator/ftpfs]] or [[hurd/translator/unionfs]], and even things that
+have very little to do with a traditional filesystem, like a
+[[gzip_translator|hurd/translator/storeio]],
+[[mbox_translator|hurd/translator/mboxfs]],
+[[xml_translator|hurd/translator/xmlfs]], or various device file translators...
+Listing all of these in `/etc/mtab` would be pretty pointless, so some kind of
+classification mechanism is necessary.  By default it probably should list only
+translators that claim to be real filesystems, though alternative views with
+other filtering rules might be desirable.
+
+After taking decisions on the outstanding design questions, the student will
+implement both the actual mtab translator, and the
+necessary interface(s) for gathering the data.  It requires getting a good
+understanding of the translator mechanism and Hurd interfaces in general.
+
+
+# IRC, freenode, #hurd, 2013-04-17
+
+    <kuldeepdhaka> thinking how to get the listing. traversing would be
+      ineffecient,   trying to come up with something better
+    <braunr> what listing ?
+    <braunr> and traversing what ?
+    <kuldeepdhaka> mtab
+    <braunr> well i assumed so
+    <braunr> be more precise please
+    <kuldeepdhaka> when the translator is done initalized      <translation
+      info> are written to /etc/mtab      <translation info> will be provided
+      by the translator, and when some one want to read the info just read it
+      this way if their is some credentials like ftp sites pass username can be
+      masked by the translator
+    <kuldeepdhaka> if some trans dont want to list them, no need to write to
+      file    | while unmounting (sorry i couldnt find the right word) , it
+      will pass the mount node address | <translation info> will have special
+      structure to remove/add mounts example "a /mount-to /mount-from" = add
+      , "r /mount-to" = remove    here "/mount-to" will be unique for every
+      mount
+    <kuldeepdhaka> this have a draw back , we would have to trust trans for the
+      listed data  | also "/mount-to" + "/mount-from" could be used a
+      combination for making sure that other trans unable remove others trans
+      mount data
+    <kuldeepdhaka> sorry but "also "/mount-to" + "/mount-from" could be used a
+      combination for making sure that other trans unable remove others trans
+      mount data"  this is a bad idea if we had to print the whole thing
+    <kuldeepdhaka> braunr, whats ur opinion?
+    <pinotree> you don't need a mtab to "unmount" things on hurd
+    <braunr> kuldeepdhaka: hum, have you read the project idea ?
+
+    <braunr> A more promising approach is to have mtab exported by a special
+      translator, which gathers the necessary information on demand. This could
+      work by traversing the tree of translators, asking each one for mount
+      points attached to it.
+    <kuldeepdhaka> pinotree, not to unmount, i mean is to remove the
+      <translation data>
+    <braunr> for a first implementation, i'd suggest a recursive traversal of
+      root-owned translators
+    <kuldeepdhaka> braunr, hum, but it did stated it as inefficient
+    <braunr> where ?
+    <kuldeepdhaka> para 5 , line 3
+    <kuldeepdhaka> and line 6
+    <braunr> no
+    <braunr> traversing "all" nodes would be inefficient
+    <braunr> translators which host the nodes of other translators could
+      maintain a simple list of active translators
+    <braunr> ext2fs, e.g. (if that's not already the case) could keep the list
+      of the translators it started
+    <braunr> we can already see that list with pstree for example
+    <braunr> but this new list would only retain those relevant for mtab
+    <braunr> i.e. root-owned ones
+    <pinotree> i would not limit to those though
+    <braunr> and then filter on their type (e.g. file system ones)
+    <braunr> pinotree: why ?
+    <pinotree> this way you could have proper per-user /proc/$pid/mounts info
+    <braunr> we could also very easily have a denial of service
+    <kuldeepdhaka> but how will the mount point and source point will be
+      listed?
+    <braunr> they're returned by the translator
+    <kuldeepdhaka> k
+    <braunr> you ask /, it returns its store and its options, and asks its
+      children recursively 
+    <braunr> a /home translator would return its store and its options
+    <braunr> etc..
+    <braunr> each translator would build the complete path before returning it
+    <braunr> sort of, it's very basic
+    <braunr> but that would be a very hurdish way to do it
+    <kuldeepdhaka> shall /etc/mtab should be made seek-able and what should be
+      the filesize?  content are generated on demand so, it could arise problem
+      (fsize:0 , seek-able:no), ur opinions?
+    <braunr> kuldeepdhaka: it should have all the properties of a regular file
+    <braunr> the filesize would be determined after it's generated
+    <braunr> being empty doesn't imply it's not seekable
+    <kuldeepdhaka> content is generated on demand so, could cause problem while
+      seeking and filesize, shall i still program as regular file?
+    <kuldeepdhaka> in two different read, it could generate different content,
+      though same seek pos is used...
+    <braunr> what ?
+    <braunr> the content is generated on open
+    <kuldeepdhaka> ooh, ok
+
+
+# IRC, freenode, #hurd, 2013-06-04
+
+    <safinaskar> how to see list of all connected translators?
+    <braunr> you can't directly
+    <braunr> you can use ps to list processes and guess which are translators
+    <braunr> (e.g. everything starting with /hurd/)
+    <braunr> a recursive call to obtain such a list would be useful
+    <braunr> similar to what's needed to implement /proc/mounts
+
+
+# IRC, freenode, #hurd, 2013-06-25
+
+In context of [[open_issues/mig_portable_rpc_declarations]].
+
+    <teythoon> should I go for an iterator like interface instead?
+    <teythoon> btw, what's the expected roundtrip time?
+    <braunr> don't think that way
+    <braunr> consider the round trip delay as varying
+    <teythoon> y, is it that bad?
+    <braunr> no
+    <braunr> but the less there is the better
+    <braunr> we think the same with system calls even if they're faster
+    <braunr> the delay itself isn't the real issue
+    <braunr> look at how proc provides information
+    <braunr> (in procfs for example)
+
+
+## IRC, freenode, #hurd, 2013-06-26
+
+    <teythoon> so tell me about the more hurdish way of dealing with that issue
+    <teythoon> creating a specialized translator for this?
+
+    <braunr> you need to avoid thinking with centralization in mind
+    <braunr> the hurd is a distributed system in practice
+    <braunr> i think proc is the only centralized component in there
+    <teythoon> braunr: would having an mtab translator and having fs
+      translators register to thae be acceptable?
+    <teythoon> that*
+    <braunr> teythoon: why do you want to centralize it ?
+    <braunr> translators already register themselves when they get attached to
+      a node
+    <braunr> we don't want an additional registration
+    <braunr> have you read the link we gave you ?
+    <teythoon> I did and I got the message, but isn't the concept of
+      /proc/mounts or a mtab file already a centralized one?
+    <braunr> that doesn't mean the implementation has to be
+    <braunr> and no, i don't think it's centralized actually
+    <braunr> it's just a file
+    <braunr> you can build a file from many sources
+    <teythoon> or if we do it your way recursing on fs translators *but*
+      restricting this to root owned translators also suffering from
+      centralization wrt to the root user? I mean the concept of all mounted
+      filesystems does not apply cleanly to the hurd
+    <braunr> i don't understand
+    <braunr> restricting to the root user doesn't mean it's centralized
+    <braunr> trust has nothing to do with being centralized
+    <teythoon> I guess I'm not used to thinking this way
+    <braunr> teythoon: i guess that's the main reason why so few developers
+      work on the hurd
+    <teythoon> also the way fs notification is done is also centralized, that
+      could also be done recursively
+    <braunr> what doyou call fs notification ?
+    <teythoon> and the information I need could just be stuffed into the same
+      mechanism
+    <teythoon> fs translators being notified of system shutdown
+    <braunr> right
+    <braunr> that gets a bit complicated because the kernel is also a
+      centralized component
+    <braunr> it knows every memory object and their pagers
+    <braunr> it manages all virtual memory
+    <braunr> there are two different issues here
+    <braunr> syncing memory and shutting down file systems
+    <braunr> the latter could be done recursively, yes
+    <braunr> i wonder if the former could be delegated to external pagers as
+      well
+    <braunr> teythoon: but that's not the focus of your work aiui, it would
+      take much time
+    <teythoon> sure, but missing an mtab file or better yet /proc/mounts could
+      be an issue for me, at least a cosmetic one, if not a functional one
+    <braunr> i understand
+    <teythoon> and hacking up a quick solution for that seemed like a good
+      exercise
+    <braunr> i suggest you discuss it with your mentors
+    <braunr> they might agree to a temporary centralized solution
+    <braunr> although i don't think it's much simpler than the recursive one
+    <teythoon> braunr: would that be implemented in libdiskfs and friends?
+    <braunr> teythoon: i'm not sure, it might be a generic fs operation
+    <braunr> libnetfs etc.. are also mount points
+    <teythoon> so where would it go if it was generic?
+    <braunr> libfshelp perhaps
+    <teythoon> translator startup is handled in start-translator-long.c, so in
+      case a startup is successful, I'd add it to a list?
+    <braunr> i'd say so, yes
+    <teythoon> would that cover all cases, passive and active translators?
+    <braunr> that's another question
+    <braunr> do we consider passive translators as mounted ?
+    <teythoon> ah, that was not what i meant
+    <braunr> i know
+    <braunr> but it's related
+    <teythoon> start b/c of accessing a passive one vs. starting an active one
+      using settrans
+    <braunr> start_translator_xxx only spawn active translators
+    <braunr> it's the same
+    <teythoon> ok
+    <braunr> the definition of a passive translator is that it starts the
+      active translator on access
+    <teythoon> yeah I can see how that wouldn't be hard to implement
+    <braunr> i think we want to include passive translators in the mount table
+    <braunr> so registration must happen before starting the active one
+    <teythoon> so it's a) keeping a list of active translators and b) add an
+      interface to query fs translators for this list and c) an interface to
+      query mtab style information?
+    <braunr> keeping a list of all translators attached
+    <braunr> and yes
+    <braunr> well
+    <braunr> a is easy
+    <braunr> b is the real work
+    <braunr> c would be procfs using b
+    <teythoon> oh? I thought recursing on the translators and querying info
+      would be separate operations?
+    <braunr> why so ?
+    <braunr> the point is querying recursively :)
+    <braunr> and when i say recursively, it's only a logical view
+    <teythoon> ok, yes, it can be implemented this way, so we construct the
+      list while recursing on the translators
+    <braunr> i think it would be better to implement it the way looking up a
+      node is done
+    <teythoon> in a loop, using a stack?
+    <braunr> iteratively
+    <braunr> a translator would provide information about itself (if
+      supported), and referrences to translators locally registered to it
+    <teythoon> could you point me to the node lookup?
+    <teythoon> ah, yes
+    <braunr> eg., you ask /, it tells you it's on /dev/hd0, read-write, with
+      options, and send rights to /home, /proc, etc..
+    <braunr> well rights, references
+    <braunr> it could be the path itself
+    <teythoon> rights as in a port to the translators?
+    <braunr> i think the path would be better but i'm not sure
+    <braunr> it would also allow you to check the permissions of the node
+      before querying
+    <teythoon> path would be nicer in the presence of stacked translators
+    <braunr> and obviously you'd have the path right away, no need to provide
+      it in the reply
+    <teythoon> true
+
+    <teythoon> braunr: if we want to list passive translators (and I agree, we
+      should), it isn't sufficient to touch libfshelp, as setting a passive
+      translator is not handled there, only the startup
+    <braunr> teythoon: doesn't mean you can't add something there that other
+      libraries will use
+    <braunr> so yes, not sufficient
+
+
+## IRC, freenode, #hurd, 2013-06-29
+
+    <teythoon> braunr: diskfs_S_fsys_set_options uses diskfs_node_iterate to
+      recurse on active translators if do_children is given
+    <teythoon> braunr: I wonder how fast that is in practice
+    <teythoon> braunr: if it's fast enough, there might not even be a need for
+      a new function in fsys.defs
+    <teythoon> and no need to keep a list of translators for that reason
+    <teythoon> braunr: if it's not fast enough, then diskfs_S_fsys_set_options
+      could use the list to speed this up
+    <braunr> teythoon: on all nodes ?
+    <teythoon> braunr: i believe so, yes, see libdiskfs/fsys-options.c
+    <braunr> teythoon: well, if it really is all node, you clearly don't want
+      that
+
+
+## IRC, freenode, #hurd, 2013-07-01
+
+    <teythoon> I've ment to ask, the shiny new fsys_get_translators interface,
+      should it return the options for the queried translator or not?
+    <braunr> i don't think it should
+    <teythoon> ok
+    <braunr> let's walk through why it shouldn't
+    <teythoon> may I assume that the last argument returned by fsys_get_options
+      is the "source"?
+    <braunr> how would you know these options ?
+    <braunr> the source ?
+    <teythoon> I wouldn't actually
+    <braunr> yes, you wouldn't
+    <braunr> you'd have to ask the translators for that
+    <braunr> so the only thing you can do is point to them
+    <teythoon> well, the device to include in the mtab file
+    <braunr> and the client asks
+    <braunr> i don't know fsys_get_options tbh
+    <teythoon> well, both tmpfs and ext2fs print an appropriate value for
+      "device" as last argument
+    <braunr> looks like a bad interface to me
+    <braunr> options should be options
+    <braunr> there should be a specific call for the device
+    <braunr> but if everyone agrees with the options order, you can do it that
+      way for now i guess
+    <teythoon> one that could be used to recreate the "mount" using either
+      mount or settrans
+    <braunr> just comment it where appropriate
+    <teythoon> I thought that'd be the point?
+    <braunr> ?
+    <teythoon> % fsysopts tmp
+    <teythoon> /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 48K
+    <braunr> where is the device ?
+    <teythoon> % settrans -ca tmp $(fsysopts tmp)
+    <braunr> 15:56 < teythoon> well, both tmpfs and ext2fs print an appropriate
+      value for "device" as last argument
+    <teythoon> 48K
+    <braunr> i don't see it
+    <braunr> really ?
+    <teythoon> yes
+    <braunr> what about ext2fs ?
+    <braunr> hm ok i see
+    <teythoon> % fsysopts /
+    <teythoon> ext2fs --writable --no-inherit-dir-group --sync=10
+      --store-type=typed device:hd0s1
+    <braunr> i don't think you should consider that as devices
+    <braunr> but really translator specific options
+    <pinotree> agree
+    <teythoon> I don't ;)
+    <teythoon> b/c the translator calling convention is hardcoded in the mount
+      utility
+    <braunr> ?
+    <teythoon> I think it's reasonable to assume that this mapping can be
+      reversed
+    <pinotree> theorically you can write a translator that takes no arguments,
+      but just options
+    <braunr> the 48K string for tmpfs is completely meaningless
+    <braunr> in fstab, it should be none
+    <pinotree> "tmpfs"
+    <braunr> the linux equivalent is the size option
+    <braunr> no, none
+    <braunr> it's totally ignored
+    <braunr> and it's recommended to set none rather than the type to avoid
+      confusion
+    <teythoon> u sure?
+    <teythoon> % settrans -cga tmp /hurd/tmpfs --mode=666 6M          
+    <teythoon> % settrans -cga tmp /hurd/tmpfs --mode=666 6M          
+    <teythoon> % fsysopts tmp
+    <teythoon> /hurd/tmpfs --writable --no-inherit-dir-group --no-sync 6M
+    <braunr> i've not explained myself clearly
+    <braunr> it's not ignored by the translator
+    <braunr> but in fstab, it should be in the options field
+    <braunr> it's not the source
+    <braunr> clearly not
+    <teythoon> ah
+    <braunr> now i'm talking about fstab, but iirc the format is similar in
+      mtab/mounts
+    <pinotree> close, but not the same
+    <braunr> yes, close
+    <teythoon> ok, so I'll put a method into libfshelp so that translators can
+      explicitly set a device and patch all existing translators to do so?
+    <braunr> teythoon: what i meant is that, for virtual vile systems (actually
+      file systems with no underlying devices), the device field is normally
+      ignored
+    <braunr> teythoon: why do you need that for exactly
+    <teythoon> right
+    <pinotree> do they even have a "device" field?
+    <braunr> (i can see why but i'd like more visibility)
+    <braunr> pinotree: not yet
+    <braunr> pinotree: that's what he wants to add
+    <braunr> but i'd like to see if there is another way to get the information
+    <braunr> 16:05 < braunr> teythoon: why do you need that for exactly
+    <teythoon> well if I'm constructing a mtab entry I need a value for the
+      device field
+    <braunr> do we actually need it to be valid ?
+    <teythoon> not necessarily I guess
+    <braunr> discuss it with your mentors then
+    <youpi> it has to be valid for e2fsck checks etc.
+    <braunr> doesn't e2fsck check fstab actually ?
+    <youpi> i.e. actually for the cases where it's trivial
+    <youpi> fstab doesn't tell it whether it's mounted
+    <youpi> I mean fsck checking whether it's mounted
+    <youpi> not fsck -a
+    <braunr> oh
+    <braunr> couldn't we ask the device instead ?
+    <braunr> looks twisted too
+    <youpi> that'd mean patching a lot of applications which do similar checks
+    <braunr> yes
+    <braunr> teythoon: propose an interface for that with your mentors then
+    <teythoon> yeah, but couldn't you lay it out a little, I mean would it be
+      one procedure or like three?
+    <braunr> 16:04 < teythoon> ok, so I'll put a method into libfshelp so that
+      translators can explicitly set a device and patch all existing
+      translators to do so?
+    <teythoon> ok
+    <braunr> why three ?
+    <teythoon> no, I mean when adding stuff to fsys.defs
+    <braunr> i understood that
+    <braunr> but why three ? :)
+    <teythoon> it'd be more generic
+    <braunr> really ?
+    <braunr> please show a quick example of what you have in mind
+    <teythoon> i honestly don't know, thus I'm asking ;)
+    <braunr> well first, this device thing bothers me
+    <braunr> when you look at how we set up our ext2fs translators, you can see
+      they use device:xxx
+    <braunr> and not /dev/xxx
+    <braunr> but ok, let's assume it's harmless
+    <teythoon> ok, but isn't the first way actually better?
+    <braunr> i think it ends up being the same
+    <braunr> ideally, that's what we want to use as device path
+    <teythoon> but you can recreate a storeio translator using the device:xxx
+      info, the node is useless for that
+    <braunr> so that we don't need to explicitely set it
+    <braunr> ?
+    <braunr> what do you mean ?
+    <teythoon> well, fsysopts / tells currently tells me device:hd0s1
+    <braunr> for /, there isn't much choice
+    <braunr> /dev isn't there yet
+    <teythoon> ah, got it
+    <teythoon> that's why it differs...
+    <braunr> differs ?
+    <braunr> from what ?
+    <braunr> other ext2fs translators are set the same way by the debian
+      installer for example
+    <teythoon> % fsysopts /media/scratch
+    <teythoon> /hurd/ext2fs --writable --no-inherit-dir-group /dev/hd1s1
+    <teythoon> here it uses the path to the node
+    <braunr> that's weird
+    <braunr> was that done by the debian installer ?
+    <teythoon> ah no, that was me
+    <braunr> :p
+    <braunr> $ fsysopts /home
+    <braunr> /hurd/ext2fs --writable --no-inherit-dir-group --store-type=device
+      hd0s6
+    <braunr> so as you can see, it's not that simple to infer the device path
+    <teythoon> oho, yet another way ;)
+    <teythoon> right then
+    <pinotree> isn't device:hd0s1 as shortcut for specifying the store type, as
+      done with --store-type=device hd0s1?
+    <braunr> but perhaps we don't need to
+    <braunr> yes it is
+    <pinotree> iirc it's something libstore does, per-store prefixes
+    <braunr> ah that sucks
+    <braunr> teythoon: you may need to normalize those strings
+    <braunr> so that they match what's in fstab
+    <braunr> i.e. unix /dev paths
+    <braunr> otherwise e2fsck still won't be able to find the translators
+      mounting the device
+    <braunr> well, if it's mounted actually
+    <braunr> it just needs to find the matching line in mtab aiui
+    <braunr> so perhaps a libfshelp function for that, yes
+    <teythoon> braunr: so you suggest adding a normalizing function to
+      libfshelp that creates a /dev/path?
+    <braunr> yes
+    <braunr> used by the call you intend to add, which returns that device
+      string as found in fstab
+    <teythoon> found in fstab? so this would only work for translators managed
+      by fstab?
+    <braunr> no
+    <teythoon> ah
+    <teythoon> a string like the ones found in fstab?
+    <braunr> yes
+    <braunr> so that fsck and friends are able to know whether a device is
+      mounted or not
+    <braunr> i don't see any other purpose for that string in mtab
+    <braunr> you'd take regular paths as they are, convert device:xxx to
+      /dev/xxx, and return "none" for the rest i suppose
+    <teythoon> ok
+    <braunr> i'm not even sure it's right
+    <braunr> youpi: are you sure it's required ?
+    <teythoon> well it's a start and I think it's not too much work
+    <braunr> aiui, e2fsck may simply find the mount point in fstab, and ask the
+      translator if it's mounted
+    <teythoon> we can refine this later on maybe?
+    <braunr> or rather, init scripts, using mountpoint, before starting e2fsck
+    <braunr> teythoon: sure
+    <teythoon> there's this mountpoint issue... I need to run fsysopts /
+      --update early in the boot process
+    <teythoon> otherwise the device ids returned by stat(2)ing / are wrong and
+      mountpoint misbehaves
+    <teythoon> i guess b/c it's the rootfs
+    <braunr> device ids ?
+    <teythoon> % stat / | grep Device
+    <teythoon> Device: 3h/3d     Inode: 2           Links: 22
+    <braunr> do you mean the major/minor identifiers ?
+    <teythoon> I do. if I don't do the --update i get seemingly random values
+    <braunr> i guess that's expected
+    <braunr> we don't have major/minor values
+    <braunr> well, they're emulated
+    <teythoon> well, if that's fixable, that'd be really nice ;)
+    <braunr> we'll never have major/minor values
+    <teythoon> yeah, I understand that
+    <braunr> but they could be fixed by MAKEDEV when creating device nodes
+    <teythoon> but not having to call fsys_set_options on the rootfs to get the
+      emulation up to speed
+    <braunr> try doing it from grub
+    <braunr> not sure it's possible
+    <braunr> but worth checking
+    <teythoon> by means of an ext2fs flag?
+    <braunr> yes
+    <braunr> if there is one
+    <braunr> i don't know the --update flag, is it new from your work ?
+    <teythoon> braunr: no, it's been there before. -oremount gets mapped to
+      that
+    <braunr> it's documented by fsysopts, but not by the ext2fs translators
+    <teythoon> libdiskfs source says something about flushing buffers iirc
+    <braunr> -s
+    <braunr> what does it do ?
+    <braunr> teythoon: ok
+    <teythoon> braunr: so the plan is to automatically generate a device path
+      from the translators argz vector but to provide the functionality so
+      translators can set a more appropriate value? did I get the last part of
+      the discussion right?
+    <braunr> not set, return
+    <teythoon> yeah return from the procedure but settable using libfshelp?
+    <braunr> why settable ?
+    <braunr> you'd have a fsys call to obtain the dev string, and the server
+      side would call libfshelp on the fly to obtain a normalized value and
+      return it
+    <teythoon> ah, make a function overrideable that returns an appropriate
+      response?
+    <braunr> overrideable ?
+    <teythoon> like netfs_append_args
+    <braunr> you wouldn't change the command line, no
+    <teythoon> isn't that done using weak references or something?
+    <teythoon> no I know
+    <braunr> sorry i'm lost then
+    <teythoon> never mind, I'll propose a patch early to get your feedback
+    <youpi> braunr: am I sure that _what_ is required?
+    <youpi> the device?
+    <youpi> e2fsck surely needs it, yes
+    <braunr> a valid device path, yes
+    <youpi> it can't rely only on fstab
+    <braunr> yes
+    <youpi> since users may mount things by hand
+    <braunr> i've used strace on it and it does perform lookups there
+    <braunr> (although i also saw uuid magic that i guess wouldn't work yet on
+      the hurd)
+
+
+## IRC, freenode, #hurd, 2013-07-03
+
+    <teythoon> I added a procedure to fsys.defs, added a server stub to my
+      tmpfs translator and wrote a simple client, but something hasn't picked
+      up the new message yet
+    <teythoon> % ./mtab tmp
+    <teythoon> ./mtab: get_translator_info: (ipc/mig) bad request message ID
+    <teythoon> I guess it's libhurduser.so from glibc, not sure though...
+    <braunr> glibc would only have the client calls
+    <braunr> what is "% ./mtab tmp" ?
+    <teythoon> mtab is my mtab tool/soon to be a translator testing thing, tmp
+      is an active tmpfs with the appropriate server stub
+    <braunr> so mtab has the client call, right ?
+    <teythoon> yes
+    <braunr> then tmpfs doesn't
+    <teythoon> so what to do about it?
+    <teythoon> i set LD_LIBRARY_PATH to my hurd builds lib dir, is that
+      preserved by settrans -a?
+    <pinotree> not really
+    <braunr> not at all
+    <braunr> there is a wiki entry about that iirc
+    <pinotree> http://darnassus.sceen.net/~hurd-web/hurd/debugging/translator/
+    <teythoon> yeah, I read it too once
+    <teythoon> ah
+    <braunr> on the other hand, using export to set the environment should do
+      the work
+    <teythoon> yes, that did the trick, thanks :)
+    * teythoon got his EOPNOPSUPP... *nomnomnom
+    <braunr> ?
+    <braunr> same error ?
+    <teythoon> well I stubbed it out
+    <braunr> oh
+    <teythoon> no, that's what I've been expecting ;)
+    <pinotree> great
+    <braunr> :)
+    <braunr> yes that's better than "mig can't find it"
+    <teythoon> braunr: in that list of active and passive translators that will
+      have to be maintained, do you expect it should carry more information
+      other than the relative path to that translator?
+    <braunr> like what ?
+    <teythoon> dunno, maybe like a port to any active translator there
+    <teythoon> should we care if any active translator dies and remove the
+      entry if there's no passive translator that could restart it again?
+    <braunr> don't add anything until you see it's necessary or really useful
+    <braunr> yes
+    <braunr> think of something like sshfs
+    <braunr> when you kill it, it's not reported by mount any more
+    <teythoon> well, for a dynamically allocated list of strings I could use
+      the argz stuff, but if we'd ever add anything else, we'd need a linked
+      list or something, maybe a hash table
+    <teythoon> yes, I thought that'd be useful
+    <braunr> use libihash for no
+    <braunr> now
+    <teythoon> braunr: but what would I use as keys? the relative path should
+      be unique (unless translators are stacked... hmmm), but that's the value
+      I'd like to store and ihash keys are pointers
+    <teythoon> stacked translators are an kinda interesting case for mtab
+      anyways...
+    <braunr> why not store the string address ?
+    <braunr> i suppose that, for stacked translators, the code querying
+      information would only return the topmost translator
+    <braunr> since this is the one which matters for regular clients (if i'm
+      right)
+    <teythoon> wouldn't that map strings that are equal but stored at different
+      locations to different values?
+    <teythoon> that'd defeat the point
+    <teythoon> I suppose so, yes
+    <braunr> then add a layer that looks for existing strings before adding
+    <braunr> the list should normally be small so a linear lookup is fine
+    <teythoon> yeah sure, but then there's little advantage of using ihash in
+      the first place, isn't it?
+    <braunr> over what ?
+    <teythoon> over not using it at all
+    <braunr> how would you store the list then ?
+    <teythoon> it's either ll or ll+ihash
+    <braunr> uh no
+    <braunr> let me check
+    <braunr> there is ihash_iterate
+    <braunr> so you don't need a linked list
+    <teythoon> so how do I store my list of strings to deduplicate the keys?
+    <braunr> you store pointers
+    <braunr> and on addition, you iterate over all entries, making sure none
+      matches the new one
+    <braunr> and if it does, you replace it i guess
+    <braunr> depending on how you design the rest
+    <teythoon> in an dynamically allocated region of memory?
+    <braunr> i don't understand
+    <braunr> your strings should be dynmaically allocate, yes
+    <teythoon> no the array of char *
+    <braunr> your data structure being managed by libihash, you don't care
+      about allocation
+    <braunr> what array ?
+    <teythoon> ah, got it...
+    <teythoon> right.
+    <braunr> there is only one structure here, an ihash of char *
+    <teythoon> yes, I got the picture ;)
+    <braunr> goo
+    <braunr> d
+    <braunr> actually, the lookup wouldn't be linear since usually, hash tables
+      have stale entries
+    <teythoon> heh... what forest?!?
+    <braunr> but that's ok
+    <braunr> teythoon: ?
+    <teythoon> the one I couldn't make out b/c of all the trees...
+    <braunr> ?
+    <teythoon> ah, it's not important. there is this saying over here, not sure
+      if there's an english equivalent
+    <braunr> ok got it
+    <braunr> we have the same in french
+    <teythoon> I ran into a problem with my prototype
+    <teythoon> if an translator is set in e. g. diskfs_S_file_set_translator,
+      how do I get the path to that node?
+    <teythoon> I believe there cannot be a way to do that, b/c the mapping is
+      not bijective
+    <braunr> it doesn't have to be
+    <teythoon> ok, so how do I get *a* path for this node?
+    <braunr> that's another question
+    <braunr> do you see how the node is obtained ?
+    <braunr> np = cred->po->np;
+    <teythoon> yes
+    <braunr> the translation occurred earlier
+    <braunr> you need to find where
+    <braunr> then perhaps, you'll need to carry the path along
+    <braunr> or if you're lucky, it will still be there somewhere
+    <teythoon> the translation from path to node?
+    <braunr> yes
+    <teythoon> doesn't that happen in the client? and the client hands a file_t
+      to the file_set_translator routine?
+    <braunr> the relative lookup can't happen in the client
+    <braunr> the server can (and often does) retain information between two
+      RPCs
+    <teythoon> uh, I can access information from a previous rpc? is that
+      considered safe?
+    <braunr> think of open() then read()
+    <braunr> a simple int doesn't carry enough information
+    <braunr> that's why it's a descriptor
+    <teythoon> ah, the server retains some state, sure
+    <braunr> what it refers to is the state retained between several calls
+    <braunr> the object being invoked by clients
+    <braunr> teythoon: what is the "passive" parameter passed to
+      diskfs_S_file_set_translator ?
+    <teythoon> braunr: argz vector of the passive translator
+    <braunr> so it is a name
+    <braunr> but we also want active translators
+    <braunr> and what is active ?
+    <teythoon> not the name of the node though
+    <teythoon> active is the port (?) to the active translator
+    <teythoon> I guess
+    <braunr> fsys_t, looks that way yes
+    <braunr> i suppose you could add the path to the peropen structure
+    <teythoon> ok
+    <braunr> see diskfs_make_peropen
+    <teythoon> braunr: but translation happens in dir_lookup
+    <teythoon> in all places I've seen diskfs_make_peropen used, the path is
+      not available
+    <teythoon> why did you point me to diskfs_make_peropen?
+    <teythoon> s/dir_lookup/diskfs_lookup/
+    <teythoon> diskfs_lookup operates on struct node, so the path would have to
+      be stored there, right?
+    <braunr> teythoon: dir_lookup should call diskfs_make_peropen
+    <braunr> at least diskfs_S_dir_lookup does
+    <braunr> and the path is present there
+    <teythoon> braunr: right
+
+    <teythoon> hrm... I added a path field to struct peropen and initialize it
+      properly in diskfs_make_peropen, but some bogus values keep creeping in
+      :/
+    <braunr> first of all, make it a dynamically allocated string
+    <teythoon> it is
+    <braunr> not a fixed sized embedded array
+    <braunr> good
+    <teythoon> yes
+    <braunr> if you really need help debugging what's happening, feel free to
+      post your current changes somewhere
+    <teythoon> there is a struct literal in fsys-getroot.c, but i fixed that as
+      well
+    <teythoon> % ./mtab tmp 
+    <teythoon> none tmp ../tmpfs/tmpfs writable,no-inherit-dir-group,no-sync 0
+      0
+    <teythoon> none tmp/bar ../tmpfs/tmpfs
+      writable,no-inherit-dir-group,no-sync 0 0
+    <teythoon> none tmp/foo ../tmpfs/tmpfs
+      writable,no-inherit-dir-group,no-sync 0 0
+    <teythoon> none tmp/foo/bar ../tmpfs/tmpfs
+      writable,no-inherit-dir-group,no-sync 0 0
+    <teythoon> :)
+
+
+## IRC, freenode, #hurd, 2013-07-10
+
+    <teythoon> btw, I read getcwd.c and got the idea
+    <teythoon> however this situation is different afaict
+    <teythoon> getcwd has a port to the current working directory, right?
+    <teythoon> so they can do open_dir with .. as relative path
+    <teythoon> but all I've got is a port referencing the node the translator
+      is being attached to
+    <teythoon> s/open_dir/dir_lookup/
+    <teythoon> and that is not necessarily a directory, so dir_lookup fails
+      with not a directory
+    <teythoon> as far as I can see it is not possible to get the directory a
+      node is in from a port referencing that node
+    <teythoon> dir_lookup has to be handled by all nodes, not just directories
+    <teythoon> but file nodes only support "looking up" the empty string
+    <teythoon> not empty, but null:
+    <teythoon> This call is required to be supported by all files (even
+      non-directories) if the filename is null, and should function in that
+      case as a re-open of the file.  */
+    <braunr> why do you want the directory ?
+    <braunr> 10:40 < teythoon> as far as I can see it is not possible to get
+      the directory a node is in from a port referencing that node
+    <teythoon> to readdir(3) it and figure out the name of the node the
+      translator is bound to
+    <teythoon> similar to what getcwd does
+    <braunr> that's out of the question
+    <teythoon> wasn't that was youpi was suggesting?
+    <braunr> you may have a lot of nodes in there, such a lookup shouldn't be
+      done
+    <braunr> i didn't see that detail
+    <teythoon> "│   Concerning storing the path, it's a bit sad to have to do
+      that, and
+    <teythoon> │   it'll become wrong if one moves the mount points.  Another
+      way would
+    <teythoon> │   be to make the client figure it out by itself from a port to
+      the mount
+    <teythoon> │   point, much like glibc/sysdeps/mach/hurd/getcwd.c. It'll be
+      slower, but
+    <teythoon> │   should be safer.  The RPC would thus return an array of
+      ports to the
+    <teythoon> │   mount points instead of an array of strings.
+    <braunr> yes i remember that
+    <braunr> but i didn't understand well how getcwd work
+    <braunr> s
+    <braunr> another scalability issue
+    <braunr> not a big one though, we rarely have translators in directories
+      with thousands of nodes
+    <braunr> so why not
+    <braunr> teythoon: do it as youpi suggested
+    <braunr> well if you can
+    <braunr> eh
+    <braunr> if not, i don't know
+    <braunr> 10:47 < teythoon> │   it'll become wrong if one moves the mount
+      points.  Another way would
+    <teythoon> yes, I know... :/
+    <teythoon> well, I'm not even sure it is possible to get the directory a
+      node is in from the port referencing the node
+    <teythoon> as in, I'm not sure if the information is even there
+    <teythoon> b/c a filesystem is a tree, directories are nodes and files are
+      leafs
+    <teythoon> all non-leaf nodes reference their parent to allow traversing
+      the tree starting from any directory
+    <teythoon> but why would a leaf reference its parent(s - in case of
+      hardlinks)?
+    <braunr> uh, for the same reason ?
+    <teythoon> sure, it would be nice to do that, but I dont think this is
+      possible on unixy systems
+    <braunr> ?
+    <teythoon> you cannot say fchdir(2) to a fd that references a file
+    <braunr> do you mean /path/to/file/../ ?
+    <teythoon> yes
+    <teythoon> only that /path/to/file is given as fd or port
+    <braunr> when i pasted
+    <braunr> 10:49 < braunr> 10:47 < teythoon> │   it'll become wrong if one
+      moves the mount points.  Another way would
+    <braunr> i was actually wondering if it was true
+    <teythoon> ah
+    <braunr> why can't the path be updated at the same time ?
+    <braunr> it's a relative path anyway
+    <braunr> completely managed by the parent translator
+    <teythoon> ah
+    <teythoon> right
+    <teythoon> it's still kind of hacky, but I cannot see how to do this
+      properly
+    <braunr> hacky ?
+    <teythoon> but yes, updating the path should work I guess
+    <teythoon> or sad
+    <braunr> what i find hacky is to set translators in two passes
+    <braunr> otherwise we'd only keep the translator paths
+    <braunr> not all paths
+    <teythoon> true
+    <braunr> but then, it only concerns open nodes
+    <braunr> and again, there shouldn't be too many of them
+    <braunr> so actually it's ok
+    <teythoon> braunr: I understand the struct nodes are cached in libdiskfs,
+      so wouldn't it be easier to attach the path to that struct instead of
+      struct peropen so that all peropen objects reference the same node
+      object?
+    <teythoon> so that the path can be updated if anyone dir_renames it
+    <teythoon> *all peropen objects derived from the same file name that is
+    <braunr> teythoon: i'm not sure
+    <braunr> nodes could be real nodes (i.e. inodes)
+    <braunr> there can be several paths for the same inode
+    <teythoon> braunr: I'm aware of that, but didn't we agree the other day
+      that any path would do?
+    <braunr> i don't remember we did
+    <braunr> i don't know the details well, but i don't think setting a
+      translator on a hard link should set the translator at the inode level
+    <braunr> on the other hand, if a new inode is created to replace the
+      previous one (or stack over it), then storing the path there should be
+      fine
+    <teythoon> braunr: I don't think I can update the paths if they're stored
+      in the peropen struct
+    <teythoon> how would I get a reference to all those peropen objects?
+    <braunr> ?
+    <braunr> first, what's the context when you talkb about updating paths ?
+    <teythoon> well, youpi was concerned about renaming a mount point
+    <teythoon> and you implied that this could be managed
+    <braunr> can we actually do that btw ?
+    <teythoon> what?
+    <braunr> renaming a mount point
+    <teythoon> yep, just tried
+    <braunr> i mean, on a regular unix system like linux
+    <braunr> $ mv test blah
+    <braunr> mv: cannot move `test' to `blah': Device or resource busy
+    <braunr> (using sshfs so YMMV)
+    <pinotree> do you have anything (shells, open files, etc) inside it?
+    <braunr> no
+    <braunr> i'll try with an empty loop-mounted ext4
+    <teythoon> I was testing on the Hurd, worked fine there even with a shell
+      inside
+    <braunr> same thing
+    <braunr> i consider it a bug
+    <braunr> we may want to check what posix says about it
+    <teythoon> o_O
+    <braunr> and decide not to support renaming
+    <teythoon> why?
+    <pinotree> start a discussion in ml, maybe roland can chime in
+    <braunr> it complicates things
+    <braunr> ah yes
+    <teythoon> sure, but I can move or rename a directory, why should it be
+      different with a mount point?
+    <braunr> because it's two of them
+    <braunr> they're stacked
+    <braunr> if we do want to support that, we must be very careful about
+      atomically updating all the stack
+    <teythoon> ok
+    <teythoon> braunr: I'm trying to detect dying translators to remove them
+      from the list of translators
+    <teythoon> what port can I use for that purpose?
+    <teythoon> if I use the bootstrap port, can I then use the same method as
+      init/init.c uses? just defining a do_mach_notify_dead_name function and
+      the multiplexer will call this?
+    <braunr> teythoon: possibly
+    <teythoon> braunr: we'll see shortly...
+    <teythoon> I get KERN_INVALID_CAPABILITY indicating that my bootstrap port
+      is invalid
+    <teythoon> when calling mach_port_request_notification to get the dead name
+      notification I mean
+    <braunr> is the translator already started when you do that ?
+    <teythoon> yes, at least I think so, I'm hooking into
+      diskfs_S_file_set_translator and that gets an active translators port
+    <teythoon> also the mach docs suggests that the notification port is
+      invalid, not the name port referencing the translator
+    <braunr> i guess it shouldn't
+    <braunr> oh
+    <braunr> please show the code
+    <braunr> but beware, if the translator is started, assume it could die
+      immediately
+    <teythoon> braunr: http://paste.debian.net/15371/ line 87
+    <braunr> teythoon: notify can't be bootstrap
+    <braunr> what do you have in mind when writing this ?
+    <braunr> i'm not sure i follow
+    <teythoon> I want to be notified if an active translator goes away to
+      remove it from the list of translators
+    <braunr> ok but then
+    <braunr> create a send-once right
+    <braunr> and wait on it
+    <braunr> also, why do you want to be notified ?
+    <braunr> isn't this already done ?
+    <braunr> or can't do it lazily on access attempt ?
+    <braunr> +you
+    <teythoon> in the client?
+    <braunr> in the parent server
+    <braunr> what happens currently when a translator dies
+    <braunr> is the parent notified ?
+    <braunr> or does it give an invalid right ?
+    <teythoon> ah, i think so
+    <braunr> then you don't need to do it again
+    <teythoon> right, I overlooked that
+
+
+## IRC, freenode, #hurd, 2013-07-12
+
+    <teythoon> recursively traversing all translators from / turns out to be
+      more dangerous than I expected
+    <teythoon> ... if done by a translator bound somewhere below /...
+    <teythoon> my interpretation is that the mtab translator tries to talk to
+      itself and deadlocks
+    <teythoon> (and as a side effect the whole system kinda just stops...)
+
+
+## IRC, freenode, #hurd, 2013-07-15
+
+    <youpi> teythoon: did you discuss with braunr about returning port vs path
+      in fsys_get_children?
+    <teythoon> youpi: we did
+    <teythoon> as I wrote I looked at the getcwd source you pointed me at
+    <teythoon> and I started to code up something similar
+    <teythoon> but as far as I can see there's no way to tell from a port
+      referencing a file the directory this file is located in
+    <youpi> ah, right, there was a [0] mail
+    <youpi> teythoon: because it doesn't have a "..", right
+    <teythoon> about Neals concerns, he's right about not covering passive
+      translators very well
+    <teythoon> but the solution he proposed was similar to what I tried to do
+      first
+    <youpi> I don't like half-covering passive translators at all, to be honest
+      :)
+    <youpi> either covering them completely, or not at all, would be fine
+    <teythoon> and then braunr convinced me that the "recursive" approach is
+      more elegant and hurdish, and I came to agree with him
+    <teythoon> youpi: one could scan the filesystem at translator startup and
+      populate the list
+    <youpi> by "Neal's solution", you mean an mtab registry?
+    <teythoon> yes
+    <braunr> so, let's see what linux does when renaming parent directories
+    <teythoon> mount points you mean?
+    <youpi> teythoon: browsing the whole filesystem just to find passive
+      translators is costly
+    <youpi> teythoon, braunr: and that won't prevent the user from unexpectedly
+      starting other translators at will
+    <braunr> scary
+    <teythoon> youpi: but that requires the privilege to open the device
+    <youpi> the fact that a passive translator is set is nothing more than a
+      user having the intent of starting a translator
+    <braunr> linux retains the original path in the mount table
+    <youpi> heh
+    <teythoon> youpi: any unprivileged user can trigger a translator startup
+    <youpi> sure, but root can do that too
+    <youpi> and expect the system to behave nicely
+    <teythoon> but if I'm root and want to fsck something, I won't start
+      translators accessing the device just before that
+    <teythoon> but if there's a passive translator targetting the device,
+      someone else might do that
+    <youpi> root does not always completely control what he's doing
+    <youpi> linux for instance does prevent from mounting a filesystem being
+      checked
+    <teythoon> but still, including passive translators in the list would at
+      least prevent anyone starting an translator by accident, isn't that worth
+      doing then?
+    <youpi> if there's a way to prevent root too, that's better than having a
+      half-support for something which we don't necessarily really want
+    <youpi> (i.e. an exclusive lock on the underlying device)
+    <teythoon> right, that would also do the trick
+    <teythoon> btw, some programs or scripts seem to hardcode /proc/mounts and
+      procfs and I cannot bind a translator to /proc/mounts since it is
+      read-only and the node does not exist
+    <kilobug> IMHO automatically starting translators is a generic feature, and
+      passive translator is just a specific instance of it; but we could very
+      well have, like an "autofs" that automatically start translators in tar
+      archives and iso images, allowing to cd into any tar/iso on the system;
+      implementing such things is part of the Hurd flexibility, the "core
+      system" shouldn't be too aware on how translators are started
+    <youpi> so in the end, storing where the active translator was started
+      first seems okayish according to what linux has been exposing for decades
+    <youpi> kilobug: indeed
+    <teythoon> it could serve a mounts with a passive translator by default, or
+      a link to /run/mtab, or an simple file so we could bind a translator to
+      that node
+    <youpi> I'd tend to think that /proc/mounts should be a passive translator
+      and /run/mtab / /etc/mtab a symlink to it
+    <youpi> not being to choose the translator is a concern however
+    <teythoon> ok, I'll look into that
+    <youpi> it could be an empty file, and people be able to set a translator
+      on it
+    <teythoon> if it had a passive translator, people still could bind their
+      own translator to it later on, right?
+    <teythoon> afaics the issue currently is mostly, that there is no mounts
+      node and it is not possible to create one
+    <youpi> right
+    <teythoon> cool
+    <youpi> so with the actual path, you can even check for caller's permission
+      to read the path
+    <youpi> i.e. not provide any more information than the user would be able
+      to get from browsing by hand
+    <teythoon> sure, that concern of Neil's is easy to address
+    <youpi> I'm not so much concerned by stale paths being shown in mtab
+    <youpi> the worst that can happen is a user not being able to umount the
+      path
+    <youpi> but he can settrans -g it
+    <youpi> (which he can't on linux ;) )
+    <teythoon> yes, and the device information is still valid
+    <youpi> yes
+    <braunr> despite the parent dir being renamed, linux is still able to
+      umount the new path
+    <teythoon> and so is our current umount
+    <braunr> good
+    <teythoon> (if one uses the mount point as argument)
+    <braunr> what's the current plan concerning /proc/mounts ?
+    <teythoon> serving a node with a passive translator record
+    <braunr> ?
+    <teythoon> so that /hurd/mtab / is started on access
+    <braunr> i mean, still planning on using the recursive approach instead of
+      a registry ?
+    <teythoon> ah
+    <teythoon> I do not feel confident enough to decide this, but I agree with
+      you, it feels elegant
+    <teythoon> and it works :)
+    <teythoon> modulo the translator deadlocking if it talks to itself, any
+      thoughts on that?
+    <youpi> it is a non-threaded translator I guess?
+    <teythoon> currently yes
+    <youpi> making it threaded should fix the issue
+    <teythoon> I tried to make the mtab translator multithreaded but that
+      didn't help
+    <youpi> that's odd
+    <teythoon> maybe I did it wrong
+    <braunr> i don't find it surprising
+    <braunr> well, not that surprising :p
+    <braunr> on what lock does it block ?
+    <teythoon> as far as i can see the only difference of hello and hellot-mt
+      is that it uses a different dispatcher and has lot's of locking, right?
+    <teythoon> braunr: I'm not sure, partly because that wrecked havoc on the
+      whole system
+    <teythoon> it just freezes
+    <teythoon> but it wasn't permanent. once i let it running and it recovered
+    <braunr> consider using a subhurd
+    <teythoon> ah right, I ment to set up one anyway, but my first attempts
+      were not successful, not sure why
+    <teythoon> anyway, is there a way to prevent this in the first place?
+    <teythoon> if one could compare ports that'd be helpful
+    <youpi> Mmm, did you try to simply compare the number?
+    <teythoon> with the bootstrap port I presume?
+    <youpi> Mmm, no, the send port and the receive port would be different
+    <youpi> no, with the receive port
+    <teythoon> ah
+    <braunr> comparing the numbers should work
+    <braunr> youpi: no they should be the same
+    <youpi> braunr: ah, then it should work yes
+    <braunr> that's why there are user ref counts
+    <youpi> ok
+    <braunr> only send-once rights have their own names
+    <teythoon> btw, I'll push my work to darnassus from now on,
+      e.g. http://darnassus.sceen.net/gitweb/?p=teythoon/hurd.git;a=shortlog;h=refs/heads/feature-mtab-translator-v3-wip
+
+
+## [[open_issues/libnetfs_passive_translators]]
+
+
+## IRC, freenode, #hurd, 2013-07-16
+
+    <teythoon> which port is the receive port of a translator? I mean, how is
+      it called in the source, there is no port in sight named receive anywhere
+      I looked.
+    <braunr> teythoon: what is the "receive port of a translator" ?
+    <teythoon> braunr: we talked yesterday about preventing the mtab deadlock
+      by comparing ports
+    <teythoon> I asked which one to use for the comparison, youpi said the
+      receive port
+    <braunr> i'm not sure what he meant
+    <braunr> it could be the receive port used for the RPC
+    <braunr> but i don't think it's exported past mig stub code
+    <teythoon> weird, I just reread it. I asked if i should use the bootstrap
+      port, and he said receive port, but it might have been addressed to you?
+    <teythoon> you were talking about send and receive ports being singletons
+      or not
+    <teythoon> umm
+    <braunr> no i answered him
+    <braunr> he was wondering if the receive port could actually be used for
+      comparison
+    <braunr> i said it can
+    <braunr> but still, i'm not sure what port
+    <braunr> if it's urgent, send him a mail
+    <teythoon> no, my pipeline is full of stuff I can do instead ;)
+    <braunr> :)
+
+
+## IRC, freenode, #hurd, 2013-07-17
+
+    <teythoon> braunr: btw, comparing ports solved the deadlock in the mtab
+      translator rather easily
+    <braunr> :)
+    <braunr> which port then ?
+    <teythoon> currently I'm stuck though, I'm not sure how to address Neals
+      concern wrt to access permission checks
+    <teythoon> I believe it's called control port
+    <braunr> ok
+    <teythoon> the one one gets from doing the handshake with the parent
+    <braunr> i thought it was the bootstrap port
+    <braunr> but i don't know the details so i may be wrong
+    <braunr> anyway
+    <teythoon> yes
+    <braunr> what is the permission problem again ?
+    <teythoon> 871u73j4zp.wl%neal@walfield.org
+    <braunr> well, you could perform a lookup on the stored path
+    <braunr> as if opening the node
+    <teythoon> if I look at any server implementation of a procedure from
+      fs.defs (say libtrivfs/file-chmod.c [bad example though, that looks wrong
+      to me]), there is permission checking being done
+    <teythoon> any server implementation of a procedure from fsys.defs lacks
+      permission checks, so I guess it's being done somewhere else
+    <braunr> i must say i'm a bit lost in this discussion
+    <braunr> i don't know :/
+    <braunr> can *you* sum up the permission problem please ?
+    <braunr> i mean here, now, in just a few words ?
+    <teythoon> ok, so I'm extending the fsys api with the get_children
+      procedure
+    <teythoon> that one should not return any children x/y if the user doing
+      the request has no read permissions on x
+    <braunr> really ?
+    <braunr> why so ?
+    <teythoon> the same way ls x would not reveal the existence of y
+    <braunr> i could also say unlike cat /proc/mounts
+    <braunr> i can see why we would want that
+    <braunr> i also can see why we could let this behaviour in place
+    <braunr> let's admit we do want it
+    <teythoon> true, but I thought this could easily be addressed
+    <braunr> what you could do is
+    <teythoon> now I'm not sure b/c I cannot even find the permission checking
+      code for any fsys_* function
+    <braunr> for each element in the list of child translators
+    <braunr> perform a lookup on the stored path on behalf of the user
+    <braunr> and add to the returned list if permission checks pass
+    <braunr> teythoon: note that i said lookup on the path, which is an fs
+      interface
+    <braunr> i assume there is no permission checking for the fsys interface
+      because it's done at the file (fs) level
+    <teythoon> i think so too, yes
+    <teythoon> sure, if I only knew who made the request in the first place
+    <teythoon> the file-* options have a convenient credential handle passed in
+      as first parameter
+    <teythoon> s/options/procedures/
+    <teythoon> surely the fsys-* procedures also have a means of retrieving
+      that information, I just don't know how
+    <braunr> mig magic
+    <braunr> teythoon: see file_t in hurd_types.defs
+    <braunr> there is the macro FILE_INTRAN which is defined in subdirectories
+      (or not)
+    <teythoon> ah, retrieving the control port requires permissions, and the
+      fsys-* operations then operate on the control port?
+    <braunr> see libdiskfs/fsmutations.h for example
+    <braunr> uh yes but that's for < braunr> i assume there is no permission
+      checking for the fsys interface because it's done at the file (fs) level
+    <braunr> i'm answering < teythoon> sure, if I only knew who made the
+      request in the first place
+    <braunr> teythoon: do we understand each other or is there still something
+      fuzzy ?
+    <teythoon> braunr: thanks for the pointers, I'll read up on that a bit
+      later
+    <braunr> teythoon: ok
+
+
+## IRC, freenode, #hurd, 2013-07-18
+
+    <teythoon> braunr: back to the permission checking problem for the
+      fsys_get_children interface
+    <teythoon> I can see how this could be easily implemented in the mtab
+      translator, it asks the translator for the list of children and then
+      checks if the user has permission to read the parent dir
+    <teythoon> but that is pointless, it has to be implemented in the
+      fsys_get_children server function
+    <braunr> yes
+    <braunr> why is it pointless ?
+    <teythoon> because one could circumvent the restriction by doing the
+      fsys_get_children call w/o the mtab translator
+    <braunr> uh no
+    <braunr> you got it wrong
+    <braunr> what i suggested is that fsys_get_children does it before
+      returning a list
+    <braunr> the problem is that the mtab translator has a different identity
+      from the users accessing it
+    <teythoon> yes, but I cannot see how to do this, b/c at this point I do not
+      have the user credentials
+    <braunr> get them
+    <teythoon> how?
+    <braunr> 16:14 < braunr> mig magic
+    <braunr> 16:15 < braunr> teythoon: see file_t in hurd_types.defs
+    <braunr> 16:16 < braunr> there is the macro FILE_INTRAN which is defined in
+      subdirectories (or not)
+    <braunr> 16:16 < braunr> see libdiskfs/fsmutations.h for example
+    <teythoon> i saw that
+    <braunr> is there a problem i don't see then ?
+    <braunr> i suppose you should define FSYS_INTRAN rather
+    <braunr> but the idea is the same
+    <teythoon> won't that change all the function signatures of the fsys-*
+      family?
+    <braunr> that's probably the only reason not to implement this feature
+      right now
+    <teythoon> then again, that change is probably easy and mechanic in nature,
+      might be an excuse to play around with coccinelle
+    <braunr> why not
+    <braunr> if you have the time
+    <teythoon> right, if this can be done, the mtab translator (if run as root)
+      could get credentials matching the users credentials to make that
+      request, right?
+    <braunr> i suppose
+    <braunr> i'm not sure it's easy to make servers do requests on behalf of
+      users on the hurd
+    <braunr> which makes me wonder if the mtab functionality shouldn't be
+      implemented in glibc eheheh ....
+    <braunr> but probably not
+    <teythoon> well, I'll try out the mig magic thing and see how painful it is
+      to fix everything ;)
+    <braunr> good luck
+    <braunr> honestly, i'm starting to think it's deviating too much from your
+      initial goal
+    <braunr> i'd be fine with a linux-like /proc/mounts
+    <braunr> with a TODO concerning permissions
+    <teythoon> ok, fine with me :)
+    <braunr> confirm it with the other mentors please
+    <braunr> we have to agree quickly on this
+    <teythoon> y?
+
+    <teythoon> braunr: I actually believe that the permission issue can be
+      addressed cleanly and unobstrusively
+    <teythoon> braunr: would you still be opposed to the get_children approach
+      if that is solved?
+    <teythoon> the filesystem is a tree and the translators "creating" that
+      tree are a more coarse version of that tree
+    <teythoon> having a method to traverse that tree seems natural to me
+    <braunr> teythoon: it is natural
+    <braunr> i'm just worried it's a bit too complicated, unnecessary, and
+      out-of-scope for the problem at hand
+    <braunr> (which is /proc/mounts, not to forget it)
+
+
+## IRC, freenode, #hurd, 2013-07-19
+
+    <teythoon> braunr: I think you could be a bit more optimistic and
+      supportive of the decentralized approach
+    <teythoon> I know the dark side has cookies and strong language and it's
+      mighty tempting
+    <teythoon> but both are bad for you :p
+
+
+## IRC, freenode, #hurd, 2013-07-22
+
+    <youpi> teythoon: AIUI, you should be able to run the mtab translator as
+      no-user (i.e. no uid)
+    <teythoon> youpi: yes, that works fine
+
+    <youpi> teythoon: so there is actually no need to define FSYS_INTRAN, doing
+      it by hand as you did is fine, right?
+    <youpi> (/me backlogs mails...)
+    <teythoon> youpi: yes, the main challenge was to figure out what mig does
+      and how the cpp is involved
+    <youpi> heh :)
+    <teythoon> my patch does exactly the same, but only for this one server
+      function
+    <teythoon> youpi: I'm confused by your mail, why are read permissions on
+      all path components necessary?
+    <braunr> teythoon: only execution normally
+    <youpi> teythoon: to avoid letting a user discover a translator running on
+      a hidden directory
+    <teythoon> braunr: exactly, and that is tested
+    <youpi> e.g. ~/home/foo is o+x, but o-r
+    <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU
+    <youpi> I don't want that to show up on /proc/mounts
+    <braunr> youpi: i don't understand either: why isn't execution permission
+      enough ?
+    <teythoon> youpi: but that requires testing for read on the *last*
+      component of the *dirname* of your translator, and that is tested
+    <youpi> let me take another example :)
+    <youpi> e.g. ~/home/foo/aZeRtYuyU is o+x, but o-r
+    <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU/foo
+    <youpi> ergl sorry, I meant this actually:
+    <teythoon> yes, that won't show up then in the mtab for users that are not
+      you and not root
+    <youpi> e.g. ~/home/foo is o+x, but o-r
+    <youpi> and I have a translator running on ~/home/foo/aZeRtYuyU/foo
+    <teythoon> ah
+    <teythoon> hmm, good point
+    <braunr> ?
+    * braunr still confused
+    <teythoon> well, qwfpgjlu is the secret
+    <teythoon> and that is revealed by the fsys_get_children procedure
+    <braunr> then i didn't understand the description of the call right
+    <braunr> > +  /* check_access performs the same permission check as is
+      normally                                                                                                                    
+    <braunr> > +     done, i.e. it checks that all but the last path components
+      are                                                                                                                    
+    <braunr> > +     executable by the requesting user and that the last
+      component is                                                                                                                  
+    <braunr> > +     readable.       */                                                                                                                                                                
+    <teythoon> braunr: youpi argues that this is not enough in this case
+    <braunr> from that, it looks ok to me
+    <youpi> the function and the documentation agree, yes
+    <youpi> but that's not what we want
+    <braunr> and that's where i fail to understand
+    <youpi> again, see my example
+    <braunr> i am
+    <braunr> 10:43 < youpi> e.g. ~/home/foo is o+x, but o-r
+    <braunr> ok
+    <youpi> so the user is not supposed to find out the secret
+    <braunr> then your example isn't enough to describe what's wron
+    <braunr> g
+    <youpi> checking read permission only on ~/home/foo/aZeRtYuyU will not
+      garantee that
+    <braunr> ah
+    <braunr> i thought foo was the last component
+    <youpi> no, that's why I changed my example
+    <braunr> hum
+    <braunr> 10:43 < youpi> e.g. ~/home/foo is o+x, but o-r
+    <braunr> 10:43 < youpi> and I have a translator running on
+      ~/home/foo/aZeRtYuyU/foo
+    <braunr> i meant, the last foo
+    <teythoon> still, this is easily fixed
+    <youpi> sure
+    <youpi> just has to be :)
+    <teythoon> youpi, braunr: so do you think that this approach will work?
+    <youpi> I believe so
+    <braunr> i still don't see the problem, so don't ask me :)
+    <braunr> i've been sick all week end and hardly slept, which might explain
+    <braunr> in the example, "all but the last path components" is
+      "~/home/foo/aZeRtYuyU"
+    <braunr> right ?
+    <youpi> braunr: well, I haven't looked at the details
+    <youpi> but be it the last, or but-last  doesn't change the issue
+    <youpi> if my ~/hidden is o-r,o+x
+    <youpi> and I have a translator on ~/hidden/a/b/c/d/e
+    <youpi> checking only +x on hidden is not ok
+    <braunr> but won't the call also check a b c d ?
+    <youpi> yes, but that's not what matters
+    <youpi> what matters is that hidden is o-r
+    <braunr> hm
+    <youpi> so the mtab translator is not supposed to reveal that there is an
+      "a" in there
+    <braunr> ok i'm starting to understand
+    <braunr> so r must be checked on all components too
+    <youpi> yes
+    <braunr> right
+    <youpi> to simulate the user doing ls, cd, ls, cd, etc.
+    <braunr> well, not cd
+    <braunr> ah
+    <youpi> for being able to do ls, you have to be able to do cd
+    <braunr> as an ordered list of commands
+    <braunr> ok
+    <teythoon> agreed. can you think of any more issues?
+    <braunr> so both x and r must be checked
+    <youpi> so in the end this RPC is really a shortcut for a find + fsysopts
+      script
+    <youpi> teythoon: I don't see any
+    <braunr> teythoon: i couldn't take a clear look at the patch but
+    <braunr> do you perform a lookup on all nodes ?
+    <teythoon> yes, all nodes on the path from the root to the one specified by
+      the mount point entry in the active translator list
+    <braunr> let me rephrase
+    <braunr> do you at some point do a lookup, similar to a find, on all nodes
+      of a translator ?
+    <teythoon> no
+    <braunr> good
+    <teythoon> yes
+    <braunr> iirc, neal raised that concern once
+    <teythoon> and I'll also fix settrans --recursive not to iterate over *all*
+      nodes either
+    <braunr> great
+    <braunr> :)
+    <teythoon> fsys_set_options with do_children=1 currently does that (I've
+      only looked at the diskfs version)
+
+
+## IRC, freenode, #hurd, 2013-07-27
+
+    <teythoon> youpi: ah, I just found msg_get_init_port, that should make the
+      translator detection feasible
+
+
+## IRC, freenode, #hurd, 2013-07-31
+
+    <teythoon> braunr: can I discover the sender of an rpc message?
+    <braunr> teythoon: no
+    <braunr> teythoon: what do you mean by "sender" ?
+    <teythoon> braunr: well, I'm trying to do permission checks in the
+      S_proc_mark_essential server function
+    <braunr> ok so, the sending user
+    <braunr> that should be doable
+    <teythoon> I've got a struct proc *p courtesy of a mig intran mutation and
+      a port lookup
+    <teythoon> but that is not necessarily the sender, right?
+    <braunr> proc is really the server i know the least :/
+    <braunr> there is permission checking for signals
+    <braunr> it does work
+    <braunr> you should look there
+    <teythoon> yes, there are permission checks there
+    <teythoon> but the only argument the rpc has is a mach_port_t refering to
+      an object in the proc server
+    <braunr> yes
+    <teythoon> anyone can obtain such a handle for any process, no?
+    <braunr> can you tell where it is exactly please ?
+    <braunr> i don't think so, no
+    <teythoon> what?
+    <braunr> 14:42 < teythoon> but the only argument the rpc has is a
+      mach_port_t refering to an object in the proc server
+    <teythoon> ah
+    <braunr> the code you're referring to
+    <braunr> a common way to give privileges to public objects is to provide
+      different types of rights
+    <braunr> a public (usually read-only) right
+    <braunr> and a privileged one, like host_priv which you may have seen
+    <braunr> acting on (modifying) a remote object normally requires the latter
+    <teythoon> http://paste.debian.net/20795/
+    <braunr> i thought you were referring to existing code
+    <teythoon> well, there is existing code doing permission checks the same
+      way I'm doing it there
+    <braunr> where is it please ?
+    <braunr> mgt.c ?
+    <teythoon> proc/mgt.c (S_proc_setowner) for example
+    <teythoon> yes
+    <braunr> that's different
+    <teythoon> but anyone can obtain such a reference by doing proc_pid2proc
+    <braunr> the sender is explicitely giving the new uid
+    <braunr> yes but not anyone is already an owner of the target process
+    <braunr> (although it may look like anyone has the right to clear the owner
+      oO)
+    <teythoon> see, that's what made me worry, it is not checked who's the
+      sender of the message
+    <teythoon> unless i'm missing something here
+    <teythoon> ah
+    <teythoon> I am
+    <teythoon> pid2proc returns EPERM if one is not the owner of the process in
+      question
+    <teythoon> all is well
+    <braunr> ok
+    <braunr> it still requires the caller process though
+    <teythoon> what?
+    <braunr> see check_owner
+    <braunr> the only occurrence i find in the hurd is in libps/procstat.c
+    <braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc (server, ps->pid,
+      &ps->process));
+    <braunr> server being the proc server AIUI
+    <teythoon> yes, most likely
+    <braunr> but pid2proc describes this first argument to be the caller
+      process
+    <teythoon> ah but it is
+    <braunr> ?
+    <teythoon> mig magic :p
+    <teythoon> MIGSFLAGS="-DPROCESS_INTRAN=pstruct_t reqport_find (process_t)"
+      \
+    <teythoon> MIGSFLAGS="-DPROCESS_INTRAN=pstruct_t reqport_find (process_t)"
+      \
+    <braunr> ah nice
+    <braunr> hum no
+    <braunr> this just looks up the proc object from a port name, which is
+      obvious
+    <braunr> what i mean is
+    <braunr> 14:53 < braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc
+      (server, ps->pid, &ps->process));
+    <braunr> this is done in libps
+    <braunr> which can be used by any process
+    <braunr> server is the proc server for this process (it defines the process
+      namespace)
+    <teythoon> yes, but isn't the port to the proc server different for each
+      process?
+    <braunr> no, the port is the same (the name changes only)
+    <braunr> ports are global non-first class objects
+    <teythoon> and the proc server can thus tell with the lookup which process
+      it is talking to?
+    <braunr> that's the thing
+    <braunr> from pid2proc :
+    <braunr> S_proc_pid2proc (struct proc *callerp
+    <braunr> [...]
+    <braunr> if (! check_owner (callerp, p))
+    <braunr> check_owner (struct proc *proc1, struct proc *proc2)
+    <braunr> "Returns true if PROC1 has `owner' privileges over PROC2 (and can
+      thus get its task port &c)."
+    <braunr> callerp looks like it should be the caller process
+    <braunr> but in libps, it seems to be the proc server
+    <braunr> this looks strange to me
+    <teythoon> yep, to me too, hence my confusion
+    <braunr> could be a bug that allows anyone to perform pid2proc
+    <teythoon> braunr: well, proc_pid2proc (getproc (), 1, ...) fails with
+      EPERM as expected for me
+    <braunr> ofc it does with getproc()
+    <braunr> but what forces a process to pass itself as the first argument ?
+    <teythoon> braunr: nothing, but what else would it pass there?
+    <braunr> 14:53 < braunr> MGET(PSTAT_PROCESS, PSTAT_PID, proc_pid2proc
+      (server, ps->pid, &ps->process));
+    <braunr> everyone knows the proc server
+    <braunr> ok now, that's weird
+    <braunr> teythoon: does getproc() return the proc server ?
+    <teythoon> I think so, yes
+    <teythoon> damn those distributed systems, all of their sources are so
+      distributed too
+    <braunr> i suspect there is another layer of dark glue in the way
+    <teythoon> I cannot even find getproc :/
+    <braunr> hurdports.c:GETSET (process_t, proc, PROC)
+    <braunr> that's the dark glue :p
+    <teythoon> ah, so it must be true that the ports to the proc server are
+      indeed process specific, right?
+    <braunr> ?
+    <teythoon> well, it is not one port to the proc server that everyone knows
+    <braunr> it is
+    <braunr> what makes you think it's not ?
+    <teythoon> proc_pid2proc (getproc (), 1, ...) fails with EPERM for anyone
+      not being root, but succeeds for root
+    <braunr> hm right
+    <teythoon> if getproc () were to return the same port, the proc server
+      couldn't distinguish these
+    <braunr> indeed
+    <braunr> in which case getproc() actually returns the caller's process
+      object at its proc server
+    <teythoon> yes, that is better worded
+    <braunr> teythoon: i'm not sure it's true actually :/
+    <teythoon> braunr: well, exploit or it didn't happen
+    <braunr> teythoon: getproc() apparently returns a bootstrap port
+    <braunr> we must find the code that sets this port
+    <braunr> i have a hard time doing that :/
+    <pinotree> isn't part of the stuff which is passed to a new process by
+      exec?
+    <teythoon> braunr: I know that feeling
+    <braunr> pinotree: probably
+    <braunr> still hard to find ..
+    <pinotree> search in glibc
+    <teythoon> braunr: exec/exec.c:1654 asks the proc server for the proc
+      object to use for the new process
+    <teythoon> so how much of hurd do I have to rebuild once i changed struct
+      procinfo in hurd_types.h?
+    <teythoon> oh noez, glibc uses it too :/
+
+
+## IRC, freenode, #hurd, 2013-08-01
+
+    <teythoon> I need some pointers on building the libc, specifically how to
+      point libcs build system to my modified hurd headers
+    <teythoon> nlightnfotis: hi
+    <teythoon> nlightnfotis: you rebuild the libc right? do you have any hurd
+      specific pointers for doing so?
+    <nlightnfotis> teythoon, I have not yet rebuild the libc (I was planning
+      to, but I followed other courses of action) Thomas had pointed me to some
+      resources on the Hurd website. I can look them up for you
+    <nlightnfotis> teythoon, here are the instructions
+      http://darnassus.sceen.net/~hurd-web/open_issues/glibc/debian/
+    <nlightnfotis> and the eglibc snapshot is here
+      http://snapshot.debian.org/package/eglibc/
+    <teythoon> nlightnfotis: yeah, I found those. the thing is I changed a
+      struct in the hurd_types.h header, so now I want to rebuild the libc with
+      that header
+    <teythoon> and I cannot figure out how to point libcs build system to my
+      hurd headers
+    <teythoon> :/
+    <nlightnfotis> can you patch eglibc and build that one instead?
+    <pochu> teythoon: put your header in the appropriate /usr/include/ dir
+    <teythoon> pochu: is there no other way?
+    <pinotree> iirc nope
+    <pochu> teythoon: you may be able to pass some flag to configure, but I
+      don't know if that will work in this specific case
+    <teythoon> ouch >,< that explains why I haven't found one
+    <pochu> check ./configure --help, it's usually FOO_CFLAGS (so something
+      like HURD_CFLAGS maybe)
+    <pochu> but then you may need _LIBS as well depending on how you changed
+      the header... so in the end it's just easier to put the header in
+      /usr/include/
+    <braunr> teythoon: did you find the info for your libc build ?
+    <teythoon> braunr: well, i firmlinked my hurd_types.h into /usr/include/...
+    <braunr> ew
+    <braunr> i recommend building debian packages
+    <teythoon> but the build was not successful, looks unrelated to my changes
+      though
+    <teythoon> I tried that last week and the process took more than eight
+      hours and did not finish
+    <braunr> use darnassus
+    <braunr> it takes about 6 hours on it
+    <teythoon> I shall try again and skip the unused variants
+    <braunr> i also suggest you use ./debian/rules build
+    <braunr> and then interrupt the build process one you see it's building
+      object files
+    <braunr> go to the hurd-libc-i386 build dir, and use make lib others
+    <braunr> make lib builds libc, others is for companion libraries lik
+      libpthread
+    <braunr> actually building libc takes less than an hour
+    <braunr> so once you validate your build this way, you know building the
+      whole debian package will succedd
+    <braunr> succeed*
+    <teythoon> so how do I get the build system to pick up my hurd_types.h?
+    <braunr> sorry if this is obvious to you, you might be more familiar with
+      debian than i am :)
+    <braunr> patch the hurd package
+    <braunr> append your own version string like +teythoon.hurd.1
+    <braunr> install it
+    <braunr> then build libc
+    <braunr> i'll reboot darnassus so you have a fresh and fast build env
+    <braunr> almost a month of uptime without any major issue :)
+    <teythoon> err, but I cannot install my hurd package on darnassus, can I? I
+      don't think that'd be wise even if it were possible
+    <braunr> teythoon: rebooted, enjoy
+    <braunr> why not ?
+    <braunr> i often do it for my own developments
+    <braunr> teythoon: screen is normally available
+    <braunr> teythoon: be aware that fakeroot-tcp is known to hang when pfinet
+      is out of ports (that's a bug)
+    <braunr> it takes more time to reach that bug since a patch that got in
+      less than a year ago, but it still happens
+    <braunr> the hurd packages are quick to build, and they should only provide
+      the new header, right ?
+    <braunr> you can include the functionality too in the packages if you're
+      confident enough
+    <teythoon> but my latest work on the killing of essential processes issues
+      involves patching hurd_types.h and that in a way that breaks the ABI,
+      hence the need to rebuild the libc (afaiui)
+    <braunr> teythoon: yes, this isn't uncommon
+    <teythoon> braunr: this is much more intrusive than anything I've done so
+      far, so I'm not so confident in my changes for now
+    <braunr> teythoon: show me the patch please
+    <teythoon> braunr: it's not split up yet, so kind of messy:
+      http://paste.debian.net/21403/
+    <braunr> teythoon: did you make sure to add RPCs at the end of defs files ?
+    <teythoon> yes, I got burned by this one on my very first attempt, you
+      pointed out that mistake
+    <braunr> :)
+    <braunr> ok
+    <braunr> you're changing struct procinfo
+    <braunr> this really breaks the abi
+    <teythoon> yes
+    <braunr> i.e. you can't do that
+    <teythoon> I cannot put it at the end b/c of that variable length array
+    <braunr> you probably should add another interface
+    <teythoon> that'd be easier, sure, but this will slow down procfs even
+      more, no?
+    <braunr> that's secondary
+    <braunr> it won't be easier, breaking the abi may break updates
+    <braunr> in which case it's impossible
+    <braunr> another way would be to ues a new procinfo struct
+    <braunr> like struct procinfo2
+    <braunr> but then you need a transition step so that all users switch to
+      that new version
+    <braunr> which is the best way to deal with these issues imo, but this time
+      not the easiest :)
+    <teythoon> ok, so I'll introduce another rpc and make sure that one is
+      extensible
+    <braunr> hum no
+    <braunr> this usually involves using a version anyway
+    <teythoon> no? but it is likely that we need to save more addresses of this
+      kind in the future
+    <braunr> in which case it will be hanlded as an independant problem with a
+      true solution such as the one i mentioned
+    <teythoon> it could return an array of vm_address_ts with a length
+      indicating how many items were returned
+    <braunr> it's ugly
+    <braunr> the code is already confusing enough
+    <braunr> keep names around for clarity
+    <teythoon> ok, point taken
+    <braunr> really, don't mind additional RPCs when first adding new features
+    <braunr> once the interface is stable, a new and improved version becomes a
+      new development of its own
+    <braunr> you're invited to work on that after gsoc :)
+    <braunr> but during gsoc, it just seems like an unnecessary burden
+    <teythoon> ok cool, I really like that way of extending Hurd, it's really
+      easy
+    <teythoon> and feels so natural
+    <braunr> i share your concern about performances, and had a similar problem
+      when adding page cache information to gnumach
+    <braunr> in the end, i'll have to rework that again
+    <braunr> because i tried to extend it beyond what i needed
+    <teythoon> true, I see how that could happen easily
+    <braunr> the real problem is mig
+    <braunr> mig limits subsystems to 100 calls
+    <braunr> it's clearly not enough
+    <braunr> in x15, i intend to use 16 bits for subsystems and 16 bits for
+      RPCs, which should be plenty
+    <teythoon> that limit seems rather artificial, it's not a power of two
+    <braunr> yes it is
+    <teythoon> so let's fix it
+    <braunr> mach had many artificial static limits
+    <braunr> eh :D
+    <braunr> not easy
+    <braunr> replies are encoded by taking the request ID and adding 100
+    <teythoon> uh
+    <braunr> "uh" indeed
+    <teythoon> so we need an intermediate version of mig that accepts both
+      id+100 and dunno id+2^x as replies for id
+    <teythoon> or -id - 1
+    <braunr> that would completely break the abi
+    <teythoon> braunr: how so? the change would be in the *_server functions
+      and be compatible with the old id scheme
+    <braunr> how do you make sure id+2^x doesn't conflict with another id ?
+    <teythoon> oh, the id is added to the subsystem id?
+    <teythoon> to obtain a global message id?
+    <braunr> yes
+    <teythoon> ah, I see
+    <teythoon> ah, but the hurd subsystems are 1000 ids apart
+    <teythoon> so id+100 or id +500 would work
+    <braunr> we need to make sure it's true
+    <braunr> always true
+    <teythoon> so how many bits do we have for the message id in mach?
+    <teythoon> (mig?)
+    <braunr> mach shouldn't care, it's entirely a mig thing
+    <braunr> well yes and no
+    <braunr> mach defines the message header, which includes the message id
+    <braunr> see mach/message.h
+    <braunr>     mach_msg_id_t       msgh_id;
+    <braunr> typedef integer_t mach_msg_id_t;
+    <teythoon> well, if that is like a 32 bit integer, then allow -id-1 as
+      reply and forbid ids > 2^x / 2
+    <braunr> yes
+    <braunr> seems reasonable
+    <teythoon> that'd give us an smooth upgrade path, no?
+    <braunr> i think so
+
+
+## IRC, freenode, #hurd, 2013-08-28
+
+    <youpi> teythoon: Mmm, your patch series does not make e.g. ext2fs provide
+      a diskfs_get_source, does it?
+
+
+## IRC, freenode, #hurd, 2013-08-29
+
+    <teythoon> youpi: that is correct
+    <youpi> teythoon: Mmm, I must be missing something then: as such the patch
+      series introduces an RPC, but only EOPNOTSUPP is ever returned in all
+      cases for now?
+    <youpi> ah
+    <youpi>  /* Guess based on the last argument. */
+    <youpi> since ext2fs & such report their options with store last, it seems
+      ok indeed
+    <youpi> it still seems a bit lame not to return that information in
+      get_source
+    <teythoon> yes
+    <teythoon> well, if it had been just for me, I would not have created that
+      rpc, but only guessing was frowned uppon iirc
+    <teythoon> then again, maybe this should be used and then the mtab
+      translator could skip any translators that do not provide this
+      information to filter out non-"filesystem" translators
+    <youpi> guessing is usually trap-prone, yes
+    <youpi> if it is to be used by mtab, then maybe it should be documented as
+      being used by mtab
+    <youpi> otherwise symlink would set a source, for instance
+    <youpi> while we don't really want it here
+    <teythoon> why would the symlink translator answer to such requests? it is
+      not a filesystem-like translator
+    <youpi> no, but the name & documentation of the RPC doesn't tell it's only
+      for filesystem-like translators
+    <youpi> well, the documentation does say "filesystem"
+    <youpi> but it does not clearly specify that one shouldn't implement
+      get_source if one is not a filesystme
+    <youpi> "If the concept of a source is applicable" works for a symlink
+    <youpi> that could be the same for eth-filter, etc.
+    <teythoon> right
+    <youpi> Mmm, that said it's fsys.defs
+    <youpi> not io.defs
+    <youpi> teythoon: it is the fact that we get EOPNOTSUPP (i.e. fsys
+      interface supported, just not that call), and not MIG_BAD_ID (i.e. fsys
+      interface not supported), that filters out symlink & such, right?
+    <teythoon> that's what I was thinking, but that's based on my
+      interpretation of EOPNOPSUPP of course ;)
+    <youpi> teythoon: I believe that for whatever is a bit questionable, even
+      if you put yourself on the side that people will probably agree on, the
+      discussion will still take place so we make sure it's the right side :)
+    <youpi> (re: start/end_code)
+    <teythoon> I'm not sure I follow
+    <teythoon> youpi: /proc/pid/stat seems to be used a lot:
+      http://codesearch.debian.net/search?q=%22%2Fproc%2F.*%2Fstat%22
+    <teythoon> that does not mean that start/endcode is used, but still it
+      seems like a good thing to mimic Linux closely
+    <youpi> stat is used a lot for cpu usage for instance, yes
+    <youpi> start/endcode, I really wonder who is using it
+    <youpi> using it for kernel thread detection looks weird to me :)
+    <youpi> (questionable): I mean that even if you take the time to put
+      yourself on the side that people will probably agree on, the discussion
+      will happen
+    <youpi> it has to happen so people know they agree on it
+    <youpi> I've seen that a lot in various projects (not only CS-related)
+    <teythoon> ok, I think I got it
+    <teythoon> it's to document the reasons for (not) doing something?
+    <youpi> something like this, yes
+    <youpi> even if you look right, people will try to poke holes
+    <youpi> just to make sure :)
+    <teythoon> btw, I think it's rather unusual that our storeio experiments
+      would produce such different results
+    <teythoon> you're right about the block device, no idea why I got a
+      character file there
+    <teythoon> I used settrans -ca /tmp/hello.unzipped /hurd/storeio -T
+      gunzip:file /tmp/hello
+    <teythoon> also I tried stacking the translator on /tmp/hello directly,
+      from what I've gathered that should be possible, but I failed
+    <teythoon> ftr I use the exec server with all my patches, so the unzipping
+      code has been removed from it
+    <youpi> ah, I probably still have it
+    <youpi> it shouldn't matter here, though
+    <teythoon> I agree
+    <youpi> how would you stack it?
+    <youpi> I've never had a look at that
+    <youpi> I'm not sure attaching the translator to the node is done before or
+      after the translator has a change to open its target
+    <teythoon> right
+    <teythoon> but it could be done, if storeio used the reference to the
+      underlying node, no?
+    <youpi> yes
+    <youpi> btw, you had said at some point that you had issues with running
+      remap. Was the issue what you fixed with your patches?
+    * youpi realizes that he should have shown the remap.c source code during
+        his presentation
+    <teythoon> well, I tried to remap /servers/exec (iirc) and that failed
+    <teythoon> then again, I recently played with remap and all seemed fine
+    <teythoon> but I'm sure it has nothing to do with my patches
+    <youpi> ok
+    <teythoon> those I came up with investigating fakeroot-hurd
+    <teythoon> and I saw that this also aplies to remap.sh
+    <teythoon> *while
+    <youpi> yep, they're basically the same
+    <teythoon> btw, I somehow feel settrans is being abused for chroot and
+      friends, there is no translator setting involved
+    <youpi> chroot, the command? or the settrans option?
+    <youpi> I don't understand what you are pointing at
+    <teythoon> the settrans option being used by fakeroot, remap and (most
+      likely) our chroot
+    <youpi> our chroot is just a file_reparent call
+    <youpi> fakeroot and remap do start a translator
+    <teythoon> yes, but it is not being bound to a node, which is (how I
+      understand it) what settrans does
+    <teythoon> the point being that if settrans is being invoked with --chroot,
+      it does something completely different (see the big if (chroot) {...}
+      blocks)
+    <teythoon> to a point that it might be better of in a separate command
+    <youpi> Mmm, indeed, a lot of the options don't make sense for chroot
+
+
+## IRC, freenode, #hurd, 2013-09-06
+
+    <braunr> teythoon: do you personally prefer /proc being able to implement
+      /proc/self on its own, or using the magic server to tell clients to
+      resolve those specific cases themselves ?
+    <pinotree> imho solving the "who's the sender of an rpc" could solve both
+      the SCM_CREDS implementation and the self case in procfs
+
+[[open_issues/SENDMSG_SCM_CREDS]],
+[[hurd/translator/procfs/jkoenig/discussion]], *`/proc/self`*.
+
+    <braunr> pinotree: yes
+    <braunr> but that would require servers impersonating users to some extent
+    <braunr> and this seems against the hurd philosophy
+    <pinotree> and there was also the fact that you could create a
+      fake/different port when sending an rpc
+    <braunr> to fake what ?
+    <pinotree> the sender identiy
+    <pinotree> *identity
+    <braunr> what ?
+    <braunr> you mean intermediate servers can do that
+    <teythoon> braunr: I don't know if I understand all the implications of
+      your question, but the magic server is the only hurd server that actually
+      implements fsys_forward (afaics), so why not use that?
+    <braunr> teythoon: my question was rather about the principle
+    <braunr> do people find it acceptable to entrust a server with their
+      authority or not
+    <braunr> on the hurd, it's clearly wrong
+    <braunr> but then it means you need special cases everywhere, usually
+      handled by glibc
+    <braunr> and that's something i find wrong too
+    <braunr> it restricts extensibility
+    <braunr> the user can always change its libc at runtime, but in practice,
+      it's harder to perform than simply doing it in the server
+    <teythoon> braunr: then I think I didn't get the question at all
+    <braunr> teythoon: it's kind of the same issue that you had with the mtab
+      translator
+    <braunr> about showing or not some entries the user normally doesn't have
+      access to
+    <braunr> this problem occurs when there is more than one server on the
+      execution path and the servers beyond the first one need credentials to
+      reply something meaningful
+    <braunr> the /proc/self case is a perfect one
+    <braunr> (conceptually, it's client -> procfs -> symlink)
+    <braunr> 1/ procfs tells the client it needs to handle this specially,
+      which is what the hurd does with magic
+    <braunr> 2/ procfs assumes the identity of the client and the symlink
+      translator can act as expected because of that
+    <braunr> teythoon: what way do you find better ?
+    <teythoon> braunr: by "procfs assumes the identity" you mean procfs
+      impersonating the user?
+    <braunr> yes
+    <teythoon> braunr: tbh I still do not see how this can be implemented at
+      all b/c the /proc/self symlink is not about identity (which can be
+      derived from the peropen struct initially created by fsys_getroot) but
+      the pid of the callee (which afaics is nowhere to be found)
+    <teythoon> s/callee/caller/
+    <teythoon> the one doing the rpc
+    <braunr> impersonating the user isn't only about identity
+    <braunr> actually, it's impersonating the client
+    <teythoon> yes, client is the term >,<
+    <braunr> so basically, asking proc about the properties of the process
+      being impersonated
+    <teythoon> proc o_O
+    <braunr> it's not hard, it's just a big turn in the way the system would
+      function
+    <braunr> teythoon: ?
+    <teythoon> you lost me somewhere
+    <braunr> the client is the process
+    <braunr> not the user
+    <teythoon> in order to implement /proc/self properly, one has to get the
+      process id of the process doing the /proc/self lookup, right?
+    <braunr> yes
+    <braunr> actually, we would even slice it more and have the client be a
+      thread
+    <teythoon> so how do you get to that piece of information at all?
+    <braunr> the server inherits a special port designating the client, which
+      allows it to query proc about its properties, and assume it's identity in
+      servers such as auth
+    <braunr> its*
+    <teythoon> ah, but that kind of functionality isn't there at the moment, is
+      it?
+    <braunr> it's not, by design
+    <teythoon> right, hence my confusion
+    <braunr> instead, servers use the magic translator to send a "retry with
+      special handling" message to clients
+    <teythoon> right, so the procfs could bounce that back to the libc handler
+      that of course knows its pid
+    <braunr> yes
+    <teythoon> right, so now at last I got the whole question :)
+    <braunr> :)
+    <teythoon> ugh, I just found the FS_RETRY_MAGICAL handler in the libc :-/
+    <braunr> ?
+    <braunr> why "ugh" ?
+    <teythoon> well, I'm inclined to think this is the bad kind of magic ;)
+    <braunr> do i need to look at the code to understand ?
+    <teythoon> ok, so I think option 1/ is easily implemented, option 2/ has
+      consequences that I cannot fully comprehend
+    <braunr> same for me
+    <teythoon> no, but you yourself said that you do not like that kind of
+      logic being implemented in the libc
+    <braunr> well
+    <braunr> easily
+    <braunr> i'm not so sure
+    <braunr> it's easy to code, but i assume checking for magic replies has its
+      cost
+    <teythoon> why not? the code is doing a big switch over the retryname
+      supplied by the server
+    <teythoon> we could stuff getpid() logic in there
+    <braunr> 14:50 < braunr> it's easy to code, but i assume checking for magic
+      replies has its cost
+    <teythoon> what kind of cost? computational cost?
+    <braunr> yes
+    <braunr> the big switch you mentioned
+    <braunr> run every time a client gets a reply
+    <braunr> (unless i'm mistaken)
+    <teythoon> a only for RETRY_MAGICAL replies
+    <braunr> but you need to test for it
+    <teythoon> 	  switch (retryname[0])
+    <teythoon> 	    {
+    <teythoon> 	    case '/':
+    <teythoon> ...
+    <teythoon> that should compile to a jump table, so the cost of adding
+      another case should be minimal, no?
+    <braunr> yes
+    <braunr> but
+    <braunr> it's even less than that
+    <braunr> the real cost is checking for RETRY_MAGICAL
+    <braunr> 14:55 < teythoon> a only for RETRY_MAGICAL replies
+    <braunr> so it's basically a if
+    <braunr> one if, right ?
+    <teythoon> no, it's switch'ing over doretry
+    <teythoon> you should pull up the code and see for yourself. it's in
+      hurd/lookup-retry.c
+    <braunr> ok
+    <braunr> well no, that's not what i'm looking for
+    <teythoon> it's not o_O
+    <braunr> i'm looking for what triggers the call to lookup_retry
+    <braunr> teythoon: hm ok, it's for lookups only, that's decent
+    <braunr> teythoon: 1/ has the least security implications
+    <teythoon> yes
+    <braunr> it could slightly be improved with e.g. a well defined interface
+      so a user could preload a library to extend it
+    <teythoon> extend the whole magic lookup thing?
+    <braunr> yes
+    <teythoon> but that is no immediate concern, you are trying to fix
+      /proc/self, right?
+    <braunr> no, i'm thinking about the big picture for x15/propel, keeping the
+      current design or doing something else
+    <teythoon> oh, okay
+    <braunr> solving /proc/self looks actually very easy
+    <teythoon> well, I'd say this depends a lot on your trust model then
+    <teythoon> do you consider servers trusted?
+    <teythoon> (btw, will there be mutual authentication of clients/servers in
+      propel?)
+    <braunr> there were very interesting discussions about that during the
+      l4hurd project
+    <braunr> iirc, shapiro insisted that using a server without trusting it
+      (and there were specific terminology about trusting/relying/etc..) is
+      nonsense
+    <braunr> teythoon: i haven't thought too much about that yet, for now it's
+      supposed to be similar to what the hurd does
+    <teythoon> hm, then again trust is not an on/off thing imho
+    <braunr> ?
+    <teythoon> trusting someone to impersonate yourself is a very high level of
+      trust
+    <teythoon> s/is/requires/
+    <teythoon> the mobile code paper suggests that mutual authentication might
+      be a good thing, and I tend to agree
+    <braunr> i'll have to read that again
+    <braunr> teythoon: for now (well, when i have time to work on it again
+      .. :))
+    <braunr> i'm focusing on the low level stuff, in a way that won't disturb
+      such high level features
+    <braunr> teythoon: have you found something related to a thread-specific
+      port in the proc server ?
+    <braunr> hurd/process.defs:297: /* You are not expected to understand
+      this. */
+    <braunr> \o/
+    <teythoon> braunr: no, why would I (the thread related question)
+    <teythoon> braunr: yes, that comment also cought my eye :/
+    <braunr> teythoon: because you read a lot of the proc code lately
+    <braunr> so maybe your view of it is better detailed than mine
+
+
+## IRC, freenode, #hurd, 2013-09-13
+
+    * youpi crosses fingers
+    <youpi> yay, still boots
+    <youpi> teythoon: I'm getting a few spurious entries in /proc/mounts
+    <youpi> none /servers/socket/26 /hurd/pfinet interface=/dev/eth0, etc.
+    <youpi> /dev/ttyp0 /dev/ttyp0 /hurd/term name,/dev/ptyp0,type,pty-master 0
+      0
+    <youpi> /dev/sd1 /dev/cons ext2fs
+      writable,no-atime,no-inherit-dir-group,store-type=typed 0 0
+    <youpi> fortunately mount drops most of them
+    <youpi> but not /dev/cons
+    <youpi> spurious entries in df are getting more and more common on linux
+      too anyway...
+    <youpi> ah, after a console restart, I don't have it any more
+    <youpi> I'm getting df: `/dev/cons': Operation not supported instead
+
+
+## IRC, freenode, #hurd, 2013-09-16
+
+    <youpi> teythoon: e2fsck does not seem to be seeing that a given filesystem
+      is mounted
+    <youpi> /dev/sd0s1 on /boot type ext2 (rw,no-inherit-dir-group)
+    <youpi> and still # e2fsck -C 0 /dev/sd0s1
+    <youpi> e2fsck 1.42.8 (20-Jun-2013)
+    <youpi> /dev/sd0s1 was not cleanly unmounted, check forced.
+    <youpi> (yes, both /etc/mtab and /run/mtab point to /proc/mounts)
+    <tschwinge> Yes, that is a "known" problem.
+    <youpi> tschwinge: no, it's supposed to be fixed by the mtab translator :)
+    <pinotree> youpi: glibc's paths.h points to /var/run/mtab (for us)
+    <tschwinge> youpi: Oh.  But this is by means of mtab presence, and not by
+      proper locking?  (Which is at least something, of course!)
+    <youpi>  /var/run points to /run
+    <youpi> tschwinge: yes
+    <youpi> anyway, got to run
+
+
+## IRC, freenode, #hurd, 2013-09-20
+
+    <braunr> teythoon: how come i see three mtab translators running ?
+    <braunr> 6 now oO
+    <braunr> looks like df -h spawns a few every time
+    <teythoon> yes, weird...
+    <braunr> accessing /proc/mounts does actually
+    <braunr> teythoon: more bug fixing for you :)
+
+
+## IRC, freenode, #hurd, 2013-09-23
+
+    <teythoon> so it might be a problem with either libnetfs (which afaics has
+      never supported passive translator records before) or procfs, but tbh I
+      haven't investigated this yet
+
+[[open_issues/libnetfs_passive_translators]].
diff --git a/hurd/translator/netio.mdwn b/hurd/translator/netio.mdwn
index 12a3f55c..885b1cc0 100644
--- a/hurd/translator/netio.mdwn
+++ b/hurd/translator/netio.mdwn
@@ -11,15 +11,16 @@ License|/fdl]]."]]"""]]
 `netio` is a translator designed for creating socket ports through the
 filesystem.
 
+This is supposed to be replaced by the better [[socketio]].
+
 
 # Source
 
 [[source_repositories/incubator]], netio/master
 
-This is supposed to be replaced by the better socketio.
 
 # Usage:
 
-e.g.
+For example:
 
-cat /tmp/netio/tcp/ftp.gnu.org/21
+    $ cat < ~/tmp/netio/tcp/ftp.gnu.org/21
diff --git a/hurd/translator/nsmux.mdwn b/hurd/translator/nsmux.mdwn
index d156772b..6b3be79c 100644
--- a/hurd/translator/nsmux.mdwn
+++ b/hurd/translator/nsmux.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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]]."]]"""]]
 
 # nsmux
 
@@ -119,3 +119,24 @@ of the simplest use-case of namespace-based translator selection in
 the form of translator `nsmux`.  The filter is partially implemented
 and this is the immediate goal.  Propagating translators down
 directories is the next objective.
+
+
+## Open Issues
+
+### IRC, freenode, #hurd, 2013-08-22
+
+[[!tag open_issue_hurd]]
+
+    < youpi> err, is nsmux supposed to work at all?
+    < youpi> a mere ls doesn't work
+    < youpi> I'm running it as a user
+    < youpi> echo * does work though
+    < teythoon> ah, yes, nsmux,,is,,funny :p
+    < youpi> well, perhaps but I can't make it work
+    < youpi> well, the trivial ,,hello does work
+    < youpi> but ,,tarfs doesn't seem to be working for instance
+    < youpi> same for ,,mboxfs
+    < youpi> ,,xmlfs seems to somehow work a bit, but not very far...
+    < youpi> so it seems just nobody is caring about putting READMEs wherever
+      appropriate
+    < youpi> e.g. examples in socketio/ ...
diff --git a/hurd/translator/pfinet.mdwn b/hurd/translator/pfinet.mdwn
index f6f69ea4..bf535b21 100644
--- a/hurd/translator/pfinet.mdwn
+++ b/hurd/translator/pfinet.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 2011 Free Software
-Foundation, Inc."]]
+[[!meta copyright="Copyright © 2002, 2004, 2005, 2007, 2008, 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
@@ -33,6 +33,9 @@ installation.
 
   * [[DHCP]].
 
+  * [[IPv6]].
+
+  * [[eth-filter]]: Firewall.
+
   * [[Implementation]].
 
-  * [[IPv6]].
diff --git a/hurd/translator/pfinet/implementation.mdwn b/hurd/translator/pfinet/implementation.mdwn
index 9bcf62ef..3e66c870 100644
--- a/hurd/translator/pfinet/implementation.mdwn
+++ b/hurd/translator/pfinet/implementation.mdwn
@@ -27,6 +27,170 @@ implementation.
     <youpi> oh
     <braunr> http://jl-icase.home.comcast.net/~jl-icase/LinuxTCP2.html
 
+## IRC, freenode, #hurd, 2013-09-03
+
+In context of the item on [[/contributing]].
+
+    <rekado> About this task: "Make pfinet OK with the ethernet device going
+      away." --- how can I test this? How can I remove the ethernet device?
+    <pinotree> settrans on the ethernet device, handled by the netdde
+      translator
+    <pinotree> that is, make it go away (settrans -fg)
+    <rekado> Ah, I see.
+    <rekado> Thanks
+    <pinotree> check its status before with showtrans
+    <pinotree> then, after having made it go away, set it again
+    <rekado> I don't think I'm doing this right... After `settrans -fg
+      /dev/eth0` I should not be able to access the network anymore, but it
+      still works.
+    <rekado> How can I figure out which of the four network devices is actually
+      used?
+    <braunr> rekado: the file system is used to open files, i.e. access
+      services
+    <braunr> it's not used to revoke access
+    <braunr> once pfinet has obtained a port to the network device, it keeps it
+    <rekado> oh, yes, of course.  Sorry, this is all very
+      new to me.
+    <rekado> I'm not sure what the problem is that this task describes.  In
+      what way is pfinet "not OK" with the ethernet device going away?
+    <braunr> rekado: the idea is to make pfinet able to cope with a driver
+      crash
+    <rekado> Can I trigger a driver crash for test purposes? (Or do I have to
+      build a purposefully broken driver first?)
+    <braunr> use kill
+    <rekado> Oh, good.
+    <braunr> iirc, netdde doesn't restart correctly :x
+    <braunr> you'll probably have to fix it a bit
+    <braunr> i guess there is some persistent state that prevents it from
+      reinitializing correctly
+    <rekado> okay
+    <rekado> I may need one more pointer: where can I find the netdde code?
+      Grep'ing around I only see it only mentioned as an argument to
+      /hurd/devnode; also: should I work in some incubator branch or directly
+      in the hurd repo?
+    <braunr> rekado: incubator branch
+    <rekado> Okay. Thank you for your patience.  I'll play with this in the
+      next few days.
+    <braunr> enjoy
+    <rekado> :)
+
+
+### IRC, freenode, #hurd, 2013-09-05
+
+    <rekado> When I kill the /hurd/netdde process I can no longer access the
+      network (as expected);
+    <rekado> To restore connectivity I run "settrans -g eth0 /hurd/devnode -M
+      /dev/netdde eth0" from the /dev directory.
+    <rekado> When I access the network again everything is fine. (I do see a
+      message telling me "irq handler 11: release an dead delivery port"
+    <rekado> )
+    <rekado> Is it the goal to avoid having to run settrans again to run netdde
+      after it crashes or is killed?
+    <youpi> you don't need to run settrans again
+    <youpi> that should get triggered automatically
+    <rekado> Hmm, after killing netdde I get "Resource lost" when using wget.
+    <rekado> It doesn't seem to be restarted automatically.
+    <youpi> try again
+    <youpi> the first wget makes pfinet try to use netdde and fail, thus crash
+    <youpi> the second wil respawn pfinet
+    <youpi> ideally pfinet shouldn't die, that's a TODO mentioned in the
+      "contributing page"
+    <rekado> Ah, so that's what should be prevented.
+    <youpi> it's just a matter of making pfinet be fine with errors from the
+      eth translator, and simply reopen it instead of dying
+    <rekado> That's the thing I've been trying to figure out.
+    <rekado> when I run wget a second (or third) time I get a different error;
+      "Name or service not known."
+    <rekado> It's only okay again when I use settrans
+    <youpi> maybe the devnode translator also needs some fixing
+    <youpi> it's odd that I don't have the issue though
+    <rekado> I'm using the qemu image, updated just yesterday.
+    <youpi> same here
+    <youpi> anyway, now you know where to put your hands :)
+    <rekado> yes, thanks a lot.
+
+
+### IRC, freenode, #hurd, 2013-09-07
+
+    <rekado> in pfinet/ethernet.c:ethernet_open there's an assertion:
+      edev->ether_port == MACH_PORT_NULL
+    <rekado> This is violated when netdde was killed and the device is
+      reopened.
+    <rekado> I'm not sure what should be done: destroy the port before
+      reopening or drop the assertion?
+    <rekado> If I drop the assertion, Mach seems to handle this just fine.
+    <rekado> Says "irq handler 11: release an [sic] dead delivery port" and
+      then carries on without problems.
+    <rekado> Is this a warning or an error, or can this be ignored?
+    <rekado> (or none of the above?)
+
+
+### IRC, freenode, #hurd, 2013-09-08
+
+    <rekado> I have a simple patch for pfinet that lets it recover from an
+      error in ethernet_xmit when /hurd/netdde and /hurd/devnode have been
+      killed.
+    <rekado> It doesn't work, though, when only netdde has been killed.
+    <rekado> With devnode still around device_open fails with "(ipc/send)
+      invalid destination port"
+    <rekado> I don't know where device_open is defined and why this error is
+      returned.
+    <rekado> I guess the error refers to the "master_device" port returned by
+      file_name_lookup() in ethernet_open()
+    <rekado> Why would file_name_lookup() return an invalid port when netdde is
+      dead but devnode is still running?
+    <braunr> rekado: maybe because devnode needs to perform a fresh lookup as
+      well
+
+
+### IRC, freenode, #hurd, 2013-09-09
+
+    <rekado> braunr: re devnode: devnode only performs a single lookup in
+      parse_opt(), i.e. at start-up.
+    <rekado> I'll try to understand devnode enough to patch it.
+    <braunr> rekado: that's the problem
+    <braunr> it should perform a lookup every time it's opened
+
+[[!message-id "1378730237-8091-1-git-send-email-rekado@elephly.net"]],
+[[!message-id "1378731824-8928-1-git-send-email-rekado@elephly.net"]].
+
+    <rekado> I submitted two patches to the mailing list.  I've tested them on
+      Debian GNU/Hurd but based them on the incubator/dde branch.
+    <teythoon> rekado: awesome, reliability fixes are very much welcome
+
+
+### IRC, freenode, #hurd, 2013-09-18
+
+    <rekado> youpi: my apologies for the delay in getting back to you with
+      improvements to my pfinet/devnode patches. Been very busy.
+    <braunr> rekado: development pace on the hurd has always been slow, no need
+      to apologize
+
+## MAC Addresses
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+    <jproulx> what command will show me the MAC address of an interface?
+    <youpi> ah, too bad inetutils-ifconfig doesn't seem to be showing it
+    <youpi> I don't think we already have a tool for that
+    <youpi> it would be a matter of patching inetutils-ifconfig
+
+
+## Routing Tables
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2013-09-21
+
+    <jproulx> Hmmm, OK I can work around that, what about routing tables, can I
+      see them?  can I add routes besides the pfinet -g default route?
+    <youpi> I don't think there is a tool for that yet
+    <youpi> it's not plugged inside pfinet anyway
+
 
 # Reimplementation, [[!GNU_Savannah_task 5469]]
 
@@ -58,3 +222,6 @@ implementation.
     <youpi> I used it for the stubdomains in Xen
     <youpi> (it = lwip)
     <braunr> ok
+
+Cloudius OSv apparently have isolated/re-used a BSD networking stack,
+<http://www.osv.io/>, <https://github.com/cloudius-systems/osv>.
diff --git a/hurd/translator/pflocal.mdwn b/hurd/translator/pflocal.mdwn
index dc2434dc..fdcc39f1 100644
--- a/hurd/translator/pflocal.mdwn
+++ b/hurd/translator/pflocal.mdwn
@@ -1,13 +1,35 @@
-[[!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 implementation of the `pflocal` server is in the `pflocal` directory, and
 uses [[`libpipe`|libpipe]] (shared code with the [[named_pipe|fifo]]
 implementation).
+
+
+# Open Issues
+
+## `SO_REUSEADDR`
+
+### IRC, freenode, #hurd, 2013-09-19
+
+    <gnu_srs> Hi, is SO_REUSEADDR supported at all on Hurd? I can only find two
+      entries: 
+    <gnu_srs> in libdde-linux26 and pfinet/linux-src, and the functionality
+      seems to be unimplemented.
+    <pinotree> gnu_srs: pfinet supports it
+    <youpi> gnu_srs: grep talks about  pfinet/linux-src/net/core/sock.c:
+      case SO_REUSEADDR:
+    <youpi> two times
+    <gnu_srs> Yes, and that is the implementation?
+    <gnu_srs> I wrote a test for AF_INET and it works, but not for AF_UNIX
+      (maybe not so interesting case).
+    <pinotree> pflocal does not support it
+    <gnu_srs> Is that of interest at all?
diff --git a/hurd/translator/proc.mdwn b/hurd/translator/proc.mdwn
new file mode 100644
index 00000000..d5e0960c
--- /dev/null
+++ b/hurd/translator/proc.mdwn
@@ -0,0 +1,75 @@
+[[!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
+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]]."]]"""]]
+
+The *proc server* (or, *process server*) implements some aspects of [[Unix]]
+processes.
+
+It is stated by `/hurd/init`.
+
+
+# "Unusual" PIDs
+
+[[!tag open_issue_hurd]]
+
+
+## IRC, freenode, #hurd, 2012-08-10
+
+    <braunr> too bad the proc server has pid 0
+    <braunr> top & co won't show it
+
+
+## IRC, OFTC, #debian-hurd, 2012-09-18
+
+    <pinotree> youpi: did you see
+      https://enc.com.au/2012/09/careful-with-pids/'
+    <pinotree> ?
+    <youpi> nope
+
+
+## IRC, OFTC, #debian-hurd, 2013-06-23
+
+    <teythoon> I've got this idea about the pid 1 issue you mentioned
+    <teythoon> can't we just make init pid 1?
+    <teythoon> I mean the mapping is rather arbitrary, we could make our init
+      pid 2 or something and start sysvs init as pid 1
+    <pinotree> not totally sure it is that arbitrary up to the first 4-5 pids
+    <teythoon> y is that?
+    <pinotree> at least i see in hurd's code that /hurd/init is assumed as
+      pid=1
+    <teythoon> hurds init that has to stick around for the fs translator sync?
+    <pinotree> hurd's init does the basic server startup
+    <pinotree> iirc it also takes care of shutdown/reboot
+    <teythoon> that's what I meant
+    <teythoon> and if it wouldn't have to stick around for the translator sync
+      it could just exec sysvinit
+    <teythoon> I just think it's easier to patch hurd than to remove the
+      assumption that init is pid 1 from sysvinit
+
+
+## IRC, freenode, #hurd, 2013-09-13
+
+    <braunr> teythoon: also, as a feature request, i'd like the proc server not
+      to have pid 0, if you have any time to do that
+    <braunr> so it appears in top and friends
+    <teythoon> braunr: noted, that should be easy
+    <teythoon> not using 0 is probably a good thing, many things use pid 0 as
+      something special
+
+
+# Process Discovery
+
+## IRC, freenode, #hurd, 2013-08-26
+
+    < teythoon> somewhat related, I do not like the way the proc server just
+      creates processes for new mach tasks it discovers
+    < teythoon> that does not play well with subhurds for example
+    < braunr> teythoon: i agree with you on proc process-to-task mapping
+    < braunr> that's something i intend to completely rework on propel
+    < braunr> in a way similar to how pid namespaces work on linux
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index d26f05f9..fc071337 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.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
@@ -14,12 +14,13 @@ License|/fdl]]."]]"""]]
 [[!toc]]
 
 
-# Miscellaneous
+# `/proc/version`
 
-IRC, #hurd, around September 2010
+[[!taglink open_issue_documentation]]: edit and move to [[FAQ]].
+
+
+## IRC, freenode, #hurd, around 2010-09
 
-    <youpi> jkoenig: is it not possible to provide a /proc/self which points at
-      the client's pid?
     <pinotree> (also, shouldn't /proc/version say something else than "Linux"?)
     <youpi> to make linux tools work, no :/
     <youpi> kfreebsd does that too
@@ -33,10 +34,103 @@ IRC, #hurd, around September 2010
     <youpi> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.3.5) #4 Sun
       Dec 18 04:30:00 CET 1977
     <pinotree> k
-    <giselher> I had some problems with killall5 to read the pid from /proc, Is
-      this now more reliable?
-    <youpi> I haven't tested with jkoenig's implementation
-    [...]
+
+
+## IRC, freenode, #hurd, 2013-06-04
+
+    <safinaskar> ?@?#@?$?@#???!?!?!?!??!?!?!?! why /proc/version on gnu system
+      reports "Linux version 2.6.1 (GNU 0.3...)"?
+    <braunr> safinaskar: because /proc/version is a linux thing
+    <braunr> applications using it don't expect to see anything else than linux
+      when parsing
+    <braunr> think of it as your web brower allowing you to set the user-agent
+    <safinaskar> braunr: yes, i just thought about user-agent, too
+    <safinaskar> braunr: but freebsd doesn't report it is linux (as well as i
+      know)
+    <braunr> their choice
+    <braunr> we could change it, but frankly, we don't care
+    <safinaskar> so why "uname" says "GNU" and not "Linux"?
+    <braunr> uname is posix
+    <braunr> note that /proc/version also includes GNU and GNU Mach/Hurd
+      versions
+    <safinaskar> if some program read the word "Linux" from /proc/version, it
+      will assume it is linux. so, i think it is bad idea
+    <braunr> why ?
+    <safinaskar> there is no standard /proc across unixen
+    <braunr> if a program reads /proc/version, it expects to be run on linux
+    <safinaskar> every unix implement his own /proc
+    <safinaskar> so, we don't need to create /proc which is fully compatible
+      with linux
+    <braunr> procfs doesn't by default
+    <safinaskar> instead, we can make /proc, which is partially compatible with
+      linux
+    <braunr> debiansets the -c compatibility flag
+    <braunr> that's what we did
+    <safinaskar> but /proc/version should really report kernel name and its
+      version
+    <braunr> why ?
+    <braunr> (and again, it does)
+    <safinaskar> because this is why /proc/version created
+    <pinotree> no?
+    <braunr> on linux, yes
+    <braunr> pinotree: hm ?
+    <safinaskar> and /proc/version should not contain the "Linux" word, because
+      this is not Linux
+    <braunr> pinotree: no to what ? :)
+    <braunr> safinaskar: *sigh*
+    <braunr> i explained the choice to you
+    <pinotree> safinaskar: if you are using /proc/version to get the kernel
+      name and version, you're doing bad already
+    <braunr> disagree if you want
+    <braunr> but there is a point to using the word Linux there
+    <pinotree> safinaskar: there's the proper aposix api for that, which is
+      uname
+    <safinaskar> pinotree: okey. so why we ever implement /proc/version?
+    <braunr> it's a linux thing
+    <braunr> they probably wanted more than what the posix api was intended to
+      do
+    <safinaskar> okey, so why we need this linux thing?   there is a lot of
+      linux thing which is useful in hurd.  but not this thing.   because this
+      is not linux.    if we support /proc/version, we should not write "Linux"
+      to it
+    <pinotree> and even on freebsd their linprocfs (mounted on /proc) is not
+      mounted by default
+    <braunr> 10:37 < braunr> applications using it don't expect to see anything
+      else than linux when parsing
+    <braunr> 10:37 < braunr> think of it as your web brower allowing you to set
+      the user-agent
+    <braunr> safinaskar: the answer hasn't changed
+    <safinaskar> pinotree: but they don't export /proc/version with "Linux"
+      word in it anyway
+    <pinotree> safinaskar: they do
+    <safinaskar> pinotree: ??? their /proc/version contain Linux?
+    <pinotree> Linux version 2.6.16 (des@freebsd.org) (gcc version 4.6.3) #4
+      Sun Dec 18 04:30:00 CET 1977
+    <kilobug> safinaskar: it's like all web browsers reporting "mozilla" in
+      their UA, it may be silly, but it's how it is for
+      compatibility/historical reasons, and it's just not worth the trouble of
+      changing it
+    <pinotree> that's on a debian gnu/kfreebsd machine
+    <pinotree> and on a freebsd machine it is the same
+    <braunr> safinaskar: you should understand that parsing this string allows
+      correctly walking the rest of the /proc tree
+    <pinotree> and given such filesystem on freebsd is called "linprocfs", you
+      can already have a guess what it is for
+    <kilobug> safinaskar: saying "Linux version 2.6.1" just means "I'm
+      compatible with Linux 2.6.1 interfaces", like saying "Mozilla/5.0 (like
+      Gecko)" in the UA means "I'm a modern browser"
+    <safinaskar> so, is there really a lot of programs which expect "Linux"
+      word in /proc/version even on non-linux platforms?
+    <braunr> no
+    <braunr> but when they do, they do
+
+
+# `/proc/self`
+
+## IRC, freenode, #hurd, around 2010-09
+
+    <youpi> jkoenig: is it not possible to provide a /proc/self which points at
+      the client's pid?
     <pinotree> looks like he did 'self' too, see rootdir_entries[] in rootdir.c
     <youpi> but it doesn't point at self
     <antrik> youpi: there is no way to provide /proc/self, because the server
@@ -56,10 +150,12 @@ IRC, #hurd, around September 2010
     <youpi> it "just" needs to be commited :)
     <antrik> in either case, it can't hurt to bring this up again :-)
 
+[[mtab/discussion]], *IRC, freenode, #hurd, 2013-09-07*.
+
 
 # root group
 
-IRC, #hurd, around October 2010
+## IRC, freenode, #hurd, around October 2010
 
     <pinotree> the only glitch is that files/dirs have the right user as
       owner, but always with root group
@@ -67,7 +163,7 @@ IRC, #hurd, around October 2010
 
 # `/proc/[PID]/stat` being 400 and not 444, and some more
 
-IRC, freenode, #hurd, 2011-03-27
+## IRC, freenode, #hurd, 2011-03-27
 
     <pochu> is there a reason for /proc/$pid/stat to be 400 and not 444 like on
       Linux?
@@ -112,7 +208,8 @@ IRC, freenode, #hurd, 2011-03-27
       /proc uses rather than rely on CLK_TCK
     <jkoenig> (so we can choose whatever reasonable value we want)
 
-IRC, freenode, #hurd, 2011-03-28
+
+## IRC, freenode, #hurd, 2011-03-28
 
     <antrik> jkoenig: does procfs expose any information that is not available
       to everyone through the proc server?...
@@ -165,7 +262,8 @@ IRC, freenode, #hurd, 2011-03-28
     <antrik> (though I never got around to look at his buggy code...)
     <jkoenig> ok
 
-IRC, freenode, #hurd, 2011-07-22
+
+## IRC, freenode, #hurd, 2011-07-22
 
     <pinotree> hm, why /proc/$pid/stat is 600 instead of 644 of linux?
     <jkoenig> pinotree, it reveals information which, while not that sensitive,
@@ -186,7 +284,7 @@ IRC, freenode, #hurd, 2011-07-22
 
 # `/proc/mounts`, `/proc/[PID]/mounts`
 
-IRC, freenode, #hurd, 2011-07-25
+## IRC, freenode, #hurd, 2011-07-25
 
     < pinotree> jkoenig: btw, what do you think about providing empty
       /proc/mounts and /proc/$pid/mounts files?
@@ -206,17 +304,34 @@ IRC, freenode, #hurd, 2011-07-25
       i don't remember)
     < pinotree> not a strict need
 
+A [[mtab]] translator now exists.
+
 
-# `/proc/[PID]/auxv`, `/proc/[PID]/exe`, `/proc/[PID]/mem`
+## IRC, freenode, #hurd, 2013-09-20
+
+    <pinotree> teythoon: should procfs now have $pid/mounts files pointing to
+      ../mounts?
+    <teythoon> pinotree: probably yes
+
+
+# `/proc/[PID]/auxv`
 
 Needed by glibc's `pldd` tool (commit
 11988f8f9656042c3dfd9002ac85dff33173b9bd).
 
 
-# `/proc/self/exe`
+# `/proc/[PID]/exe`
+
+Needed by glibc's `pldd` tool (commit
+11988f8f9656042c3dfd9002ac85dff33173b9bd).
+
+
+## `/proc/self/exe`
 
 [[!message-id "alpine.LFD.2.02.1110111111260.2016@akari"]].  Needed by glibc's
 `stdlib/tst-secure-getenv.c`.
+`HAVE_PROC_SELF_EXE` in `[GCC]/libjava/configure.ac`.
+Also used in `[GCC]/libgfortran/runtime/main.c`:`store_exe_path`.
 
 Is it generally possible to use something like the following instead?
 Disadvantage is that every program using this needs to be patched.
@@ -314,32 +429,25 @@ This is used in `[LLVM]/lib/Support/Unix/Path.inc`.
       report why the test suite failed
 
 
-# `/proc/[PID]/cwd`
+## `/proc/self/maps`
 
-## IRC, freenode, #hurd, 2012-06-30
-
-    * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
-        on "internal" (but exported) glibc functions
+`HAVE_PROC_SELF_MAPS` in `[GCC]/libjava/configure.ac`.
+Also used in `[GCC]/intl/relocatable.c`:`find_shared_library_fullname` for
+`#ifdef __linux__`.
 
 
-# "Unusual" PIDs
+# `/proc/[PID]/mem`
 
-Not actually related to procfs, but here seems to be a convenient place for
-filing these:
-
-
-## IRC, freenode, #hurd, 2012-08-10
+Needed by glibc's `pldd` tool (commit
+11988f8f9656042c3dfd9002ac85dff33173b9bd).
 
-    <braunr> too bad the proc server has pid 0
-    <braunr> top & co won't show it
 
+# `/proc/[PID]/cwd`
 
-## IRC, OFTC, #debian-hurd, 2012-09-18
+## IRC, freenode, #hurd, 2012-06-30
 
-    <pinotree> youpi: did you see
-      https://enc.com.au/2012/09/careful-with-pids/'
-    <pinotree> ?
-    <youpi> nope
+    * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
+        on "internal" (but exported) glibc functions
 
 
 # CPU Usage
diff --git a/hurd/translator/socketio.mdwn b/hurd/translator/socketio.mdwn
index 99a28416..de5cf252 100644
--- a/hurd/translator/socketio.mdwn
+++ b/hurd/translator/socketio.mdwn
@@ -11,15 +11,36 @@ License|/fdl]]."]]"""]]
 `socketio` is a translator designed for creating socket ports through the
 filesystem.
 
+This is supposed to replace [[netio]].
+
 
 # Source
 
 [[source_repositories/incubator]], socketio/master
 
-This is supposed to replace netio.
 
 # Usage:
 
-e.g.
+For example:
+
+    $ cat < ~/tmp/socketio/tcp/ftp.gnu.org/21
+
+
+# Open Issues
+
+## IRC, freenode, #hurd, 2013-06-30
+
+[[!tag open_issue_hurd]]
 
-cat /tmp/socketio/tcp/ftp.gnu.org/21
+    <youpi> http://lists.gnu.org/archive/html/bug-hurd/2003-05/msg00069.html
+    <youpi> this was supposed to be much better than our current netio
+    <youpi> (which doesn't really have any documentation btw)
+    <teythoon>
+      http://web.archive.org/web/20060117085538/http://duesseldorf.ccc.de/~moritz/files/socketio.c.gz
+    <teythoon> youpi: socketio looks nice. any reason in particular why you are
+      working on it?
+    <youpi> teythoon: I was looking at the firewall stuff, and wondering about
+      Zheng Da's work, and seen netio, thus wondered "what is it about
+      already?" and found there was no documentation, so dug into the mailing
+      list archives, only to find it was supposed to be precated in favour of
+      socketio, etc. :)
diff --git a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
index 5228515f..16a23405 100644
--- a/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
+++ b/hurd/translator/tmpfs/tmpfs_vs_defpager.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011, 2013 Free Software Foundation,
+Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -270,3 +271,129 @@ See also: [[open_issues/resource_management_problems/pagers]].
     <antrik> only problem is that the current defpager implementation can't
       really handle that...
     <antrik> at least that's my understanding of the situation
+
+
+# IRC, freenode, #hurd, 2013-07-05
+
+    <teythoon> btw, why does the tmpfs translator have to talk to the pager?
+    <teythoon> to get more control about how the memory is paged out?
+    <teythoon> read lot's of irc logs about tmpfs on the wiki, but I couldn't
+      find the answer to that
+    <mcsim> teythoon: did you read this?
+      http://www.gnu.org/software/hurd/hurd/translator/tmpfs/tmpfs_vs_defpager.html
+    <teythoon> mcsim: I did
+    <mcsim> teythoon: Last discussion, i think has very good point.
+    <mcsim> To provide memory objects you should implement pager interface
+    <mcsim> And if you implement pager interface you are the one who is asked
+      to write data to backing storage to evict them
+    <mcsim> But tmpfs doesn't do this
+    <teythoon> mmm, clients doing mmap...
+    <mcsim> teythoon: You don't have mmap
+    <mcsim> teythoon: mmap is implemented on top of mach interface
+    <mcsim> teythoon: I mean you don't have mmap at this level
+    <teythoon> mcsim: sure, but that's close enough for me at this point
+    <mcsim> teythoon: diskfs interface requires implementor to provide a memory
+      object port (send right)
+    <mcsim> Guest8183: Why tmpfs requires defpager
+    <Guest8183> how did you get to talk about that ?
+    <mcsim> I was just asked
+    <teythoon> Guest8183: it's just so unsettling that tmpfs has to be started
+      as root :/
+    <Guest8183> teythoon: why ?
+    *** Guest8183 (~rbraun@dalaran.sceen.net) is now known as braunr_
+    <teythoon> braunr_: b/c starting translators isn't a privileged operation,
+      and starting a tmpfs translator that doesn't even access any device but
+      "just" memory shouldn't require any special privileges as well imho
+    <teythoon> so why is tmpfs not based on say libnetfs? b/c it is used for
+      d-i and someone (apt?) mmaps stuff?
+    <pinotree> being libdiskfs-based isn't much the issue, iirc
+    <pinotree> http://lists.gnu.org/archive/html/bug-hurd/2013-03/msg00014.html
+      too
+    <kilobug> teythoon: AFAIK apt uses mmap, yes
+    <braunr_> teythoon: right
+    <braunr_> a ramfs is actually tricky to implement well
+    <mcsim> braunr_: What do you mean under "to implement well"?
+    <braunr_> as efficiently as possible
+    <braunr_> i.e. being as close as possible to the page cache for minimum
+      overhead
+    <mcsim> braunr: AFAIK ramfs should not use swap partition, so page cache
+      shouldn't be relevant for it.
+    <braunr> i'm talking about a ramfs in general
+    <braunr> not the specific linux ramfs
+    <braunr> in linux, what they call ramfs is the tiny version of tmpfs that
+      doesn't use swap
+    <braunr> i actually don't like "tmpfs" much
+    <braunr> memfs may be more appropriate
+    <braunr> anyway
+    <mcsim> braunr: I see. And do you consider defpager variant as "close as
+      possible to the page cache"?
+    <braunr> not far at least
+    <braunr> if we were able to use it for memory obects, it would be nice
+    <braunr> but defpager only gets attached to objects when they're evicted
+    <braunr> before that, anonymous (or temporary, in mach terminology) objects
+      have no backing store
+    <braunr> this was probably designed without having tmpfs in mind
+    <braunr> i wonder if it's possible to create a memory object without a
+      backing store
+    <mcsim> what should happen to it if kernel decides to evict it?
+    <braunr> it sets the default pager as its backing store and pushes it out
+    <mcsim> that's how it works now, but you said "create a memory object
+      without a backing store"
+    <braunr> mach can do that
+    <braunr> i was wondering if we could do that too from userspace
+    <mcsim> mach does not evict such objects, unless it bound a defpager to
+      them
+    <mcsim> but how can you handle this in userspace?
+    <braunr> i mean, create a memory object with a null control port
+    <braunr> mcsim: is that clearer ?
+    <mcsim> suppose you create such object, how kernel will evict it if kernel
+      does not know who is responsible for eviction of this object?
+    <braunr> it does
+    <braunr> 16:41 < braunr> it sets the default pager as its backing store and
+      pushes it out
+    <braunr> that's how i intend to do it on x15 at least
+    <braunr> but it's much simpler there because uvm provides better separation
+      between anonymous and file memory
+    <braunr> whereas they're much too similar in mach vm
+    <mcsim> than what the difference between current situation, when you
+      explicitly invoke defpager to create object and implicit method you
+      propose?
+    <braunr> you don't need a true defpager unless you actually have swap
+    <mcsim> ok
+    <mcsim> now I see
+    <braunr> it also saves the communication overhead when initializing the
+      object
+    <mcsim> thank you
+    <braunr> which may be important since we use ramfs for speed mostly
+    <mcsim> agree
+    <braunr> it should also simplify the defpager implementation, since it
+      would only have a single client, the kernel
+    <braunr> which may also be important with regard to global design
+    <braunr> one thing which is in my opinion very wrong with mach is that it
+      may be a client
+    <braunr> a well designed distributed system should normally not allow on
+      component to act as both client and server toward another
+    <braunr> i.e. the kernel should only be a server, not a client
+    <braunr> and there should be a well designed server hierarchy to avoid
+      deadlocks
+    <braunr> (such as the one we had in libpager because of that)
+    <mcsim> And how about filesystem? It acts both as server and as client
+    <braunr> yes
+    <braunr> but not towards the same other component
+    <braunr> application -> file system -> kernel
+    <braunr> no "<->"
+    <braunr> the qnx documentation explains that quite well
+    <braunr> let me see if i can find the related description
+    <mcsim> Basically, I've got your point. And I would rather agree that
+      kernel should not act as client
+    <braunr> mcsim:
+      http://www.qnx.com/developers/docs/6.4.0/neutrino/sys_arch/ipc.html#Robust
+    <braunr> one way to implement that (and qnx does that too) is to make
+      pagers act as client only
+    <braunr> they sleep in the kernel, waiting for a reply
+    <braunr> and when the kernel needs to evict something, a reply is sent
+    <braunr> (qnx doesn't actually do that for paging, but it's a general idea)
+    <mcsim> braunr: how hierarchy of senders is enforced?
+    <braunr> it's not
+    <braunr> developers must take care
+    <braunr> same as locking, be careful about it
diff --git a/hurd/translator/ufs.mdwn b/hurd/translator/ufs.mdwn
new file mode 100644
index 00000000..4d611e95
--- /dev/null
+++ b/hurd/translator/ufs.mdwn
@@ -0,0 +1,38 @@
+[[!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]]."]]"""]]
+
+The `ufs` translator supports some kind of the Unix File System.  Beware, we're
+not aware of anybody having used/tested it in ages, so maybe it is very broken
+and will eat your data.
+
+
+# IRC, freenode, #hurd, 2013-08-30
+
+[[!tag open_issue_hurd]]
+
+    <Arne`> There might be a copyright problem: <nalaginrut> well, there seems
+      BSD-4clauses in the code:
+      http://git.savannah.gnu.org/cgit/hurd/hurd.git/tree/ufs/alloc.c
+    <Arne`> braunr, tschwinge: Do you have any info on that? 4-clause BSD and
+      GPL on the same code are a license incompatibility… 
+    <tschwinge> Arne`: I've put it onto my (long) TODO list.
+    <tschwinge> Easiest solution might be: rm -rf ufs.
+    <nalaginrut> will these affected code rewritten? or just modify license?
+    <mark_weaver> only the regents of the University of California could choose
+      to modify the license.
+    <youpi> nalaginrut: one can't modify a licence if one is not the author
+    <youpi> we can simply dump the code
+    <mark_weaver> s/author/owner/
+    <tschwinge> As I suppose ufs is unused/untested for a decade or so, I'd
+      have no issues with simply removing it from the tree, together with
+      ufs-fsck and ufs-utils.
+    <pinotree> tschwinge: or maybe extract the ufs stuff in an own repo, to be
+      imported as branch in incubator or own hurd/ufs.git?
+    <tschwinge> Sure, why not.