Merge remote-tracking branch 'fp/master'

14 files changed, 314 insertions, 10 deletions

diff --git a/hurd/console/discussion.mdwn b/hurd/console/discussion.mdwn
new file mode 100644
index 00000000..f887d826
--- /dev/null
+++ b/hurd/console/discussion.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-09-24
+
+    <allesa> hello, I'm trying to get familiar with the Hurd and would like to
+      change the keyboard layout in use. It seems all the information I can
+      find (relating to console-driver-xkb) is out of date, with the latest
+      info relating to it being that this package should not be used anymore…
+    <allesa> does anyone know how changing keyboard layouts currently works?
+    <allesa> ah, never mind. I assume it doesn't currently work:
+      http://www.gnu.org/software/hurd/hurd/console.htmlq
+    <allesa> *http://www.gnu.org/software/hurd/hurd/console.html
+    <youpi> it does actually work
+    <youpi> simply dpkg-reconfigure keyboard-configuration
+    <youpi> and reboot
+    <youpi> (see http://www.debian.org/ports/hurd/hurd-install
+    <youpi> )
+    <allesa> mhm, I got that far — but selecting my layout gave me no joy, even
+      after restart. Seem to be stuck with the layout chosen during
+      installation (d-i). Just to check I'm using the right version — still on
+      the installer isos from 15 July?
+    <allesa> wait… progress is being made — slowly and subtly… 
+    <allesa> Ok, so the XKBLAYOUT is changing as you described, but XKBVARIANT
+      seems to be ignored. Could this be right?
+    <youpi> yes, the hurd console only supports keymaps
+    <youpi> (currently)
+    <allesa> Ah OK, thanks for your help on this. I imagine this is not
+      something that just requires simple repetitive work, but some actual
+      hacking?
+    <allesa> to fix that is…
+    <youpi> some hacking yes
diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index df6290f7..c506861a 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -167,6 +167,14 @@ See `rpctrace --help` about how to use it.
           Debian-specific, but not ready for upstream either...
         <youpi> antrik: yes
 
+* IRC, freenode, #hurd, 2012-07-18
+
+        <braunr> hm, rpctrace on gitk gives an interesting result
+        <braunr>   152<--153(pid1849)->io_set_all_openmodes_request (267) = 0 
+        <braunr> rpctrace:
+          /home/rbraun/hd0s7/hurd/hurd-20120710/./utils/rpctrace.c:1287:
+          trace_and_forward: Assertion `reply_type == 18' failed.
+
 
 # See Also
 
diff --git a/hurd/libstore/nbd_store.mdwn b/hurd/libstore/nbd_store.mdwn
index 5874b162..4d4a769f 100644
--- a/hurd/libstore/nbd_store.mdwn
+++ b/hurd/libstore/nbd_store.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2012 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -10,3 +10,8 @@ is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
 [[!meta title="nbd store: Linux-compatible network block device"]]
+
+
+# Open Issues
+
+  * [[!GNU_Savannah_task 5722]]
diff --git a/hurd/libthreads.mdwn b/hurd/libthreads.mdwn
index 8b1a97e6..c8d819d4 100644
--- a/hurd/libthreads.mdwn
+++ b/hurd/libthreads.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -13,10 +13,14 @@ License|/fdl]]."]]"""]]
 
 # Internals
 
+## Threading Model
+
+libthreads has a 1:1 threading model.
+
 
 ## Threads' Death
 
-C threads death doesn't actually free the thread's stack (and maybe not the
+A thread's death doesn't actually free the thread's stack (and maybe not the
 associated Mach ports either).  That's because there's no way to free the stack
 after the thread dies (because the thread of control is gone); the stack needs
 to be freed by something else, and there's nothing convenient to do it.  There
@@ -26,3 +30,5 @@ However, it isn't really a leak, because the unfreed resources do get used for
 the next thread.  So the issue is that the shrinkage of resource consumption
 never happens, but it doesn't grow without bounds; it just stays at the maximum
 even if the current number of threads is lower.
+
+The same issue exists in [[libpthread]].
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index 512ea602..3648c7d6 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -105,6 +105,16 @@ If your machine supports hardware acceleration, you should really use the kvm va
 
 to the command line, see below, if you are running Linux kernels 2.6.37 or 2.6.38 else IRQs may hang sooner or later. The kvm irq problems will be solved in kernel 2.6.39. 
 
+IRC, freenode, #hurd, 2012-08-29:
+
+    <braunr> youpi: do you remember which linux versions require the
+      -no-kvm-irqchip option ?
+    <braunr> your page indicates 2.6.37-38, but i'm seeing weird things on
+      2.6.32
+    <braunr> looks like a good thing to use that option all the time actually
+    <gnu_srs> seems like kvm -h says: -no-kvm-irqchip and man kvm says:
+      -machine kernel_irqchip=off
+
 /!\ Note that there are known performance issues with KVM on Linux 2.6.39
 kernels, compared to 2.6.32: [[!debbug 634149]].  We're preparing on a change
 on our side to work around this.
diff --git a/hurd/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn
index c9ec4d34..74f1c8f5 100644
--- a/hurd/settrans/discussion.mdwn
+++ b/hurd/settrans/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -16,3 +16,24 @@ License|/fdl]]."]]"""]]
     <antrik> ugh... I just realized why settrans -a without -f doesn't
       generally work on filesystem translators
     <antrik> obviously, it needs -R too!
+
+
+# IRC, freenode, #hurd, 2012-08-17
+
+    <antrik> youpi: no, only the -g is redundant; i.e. -ga is the same as -a
+    <antrik> (actually, not redundant, but rather simply meaningless in this
+      case)
+    <antrik> -g tells what to do with an active translator *when a passive one
+      is changed*
+    <antrik> if no passive one is changed, it does nothing
+    <antrik> (and I realized that after using the Hurd for only 6 years or so
+      ;-) )
+    <braunr> it's not obvious
+    <antrik> braunr: indeed. it's not obvious at all from the --help output :-(
+    <antrik> not sure though how to make it clearer
+    <braunr> the idea isn't obvious
+    <braunr> perhaps telling that "setting a passive translator" also applies
+      to removing it, i.e. setting it to none
+    <antrik> braunr: well, the fact that a translator is unset by setting it to
+      nothing is unclear in general, not only for passive translator. I agree
+      that pointing this out should make things much more clear in general...
diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn
index 3449edcd..c4fc047f 100644
--- a/hurd/subhurd/discussion.mdwn
+++ b/hurd/subhurd/discussion.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
 id="license" text="Permission is granted to copy, distribute and/or modify this
@@ -8,9 +8,10 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
 is included in the section entitled [[GNU Free Documentation
 License|/fdl]]."]]"""]]
 
-[[!tag open_issue_documentation]]
+[[!tag open_issue_documentation open_issue_hurd]]
 
-IRC, freenode, #hurd, 2011-08-10
+
+# IRC, freenode, #hurd, 2011-08-10
 
     < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ?
     < youpi> no idea
@@ -67,3 +68,92 @@ IRC, freenode, #hurd, 2011-08-10
     < antrik> I don't think that's actually supported in the boot
       program... but it doesn't really matter, as you don't really need the
       terminal anyways -- you can always log in through the network
+
+
+# IRC, freenode, #hurd, 2012-07-31
+
+    <gg0> subhurd seems like bsd jail (tried none of them)
+    <antrik> gg0: nope. BSD jails are mostly chroot AIUI. subhurd is quite
+      different
+    <antrik> gg0: you actually boot a completely new system instance
+    <antrik> complete with all the Hurd servers, UNIX daemons etc.
+    <braunr> jails are between subhhurds and chroots :p
+    <braunr> i suppose there is nothing against making the root server of the
+      subhurd use a file instead of a raw disk, is there ?
+    <gg0> well, I said jails cos afaik are more isolated from real system than
+      chroots
+    <braunr> yes
+    <gg0> maybe comparing subhurd to virtual machines would be more
+      appropriated then
+    <braunr> they're not VMs either
+    <gg0> say chroot -> jail -> subhurd -> vm ?
+    <braunr> unless you consider the microkernel to be a hypervisor, with its
+      own architecture, which some actually do
+    <braunr> gg0: something like that, yes
+    <gg0> [system-in-system evolution]
+    <braunr> a subhurd is an operating system instance
+    <braunr> i think the closest analogy you can get is openvz
+    <antrik> yeah, I'd also consider it closest. but it's still quite
+      different: with OpenVZ, the kernel facilities are only logically
+      isolated; but they use the same kernel code. with subhurds, most of the
+      system facilities are independent
+
+
+# IRC, freenode, #hurd, 2012-08-03
+
+    <antrik> hm... are Mach task IDs exposed to userspace?
+    <braunr> antrik: ids ?
+    <braunr> antrik: what do you call a mach task id ?
+    <antrik> task have numeric IDs in the kernel
+    <antrik> I wonder whether these are ever exposed to userspace
+    <braunr> i'm not sure
+    <braunr> i don't remember the had numeric IDs
+    <braunr> they*
+    <antrik> well, perhaps I'm making things up... but I believe I saw such IDs
+      in the debugger and/or in error messages
+    <braunr> probably their address
+    <braunr> or creation time orpc_sample
+    <antrik> braunr: well, any unique ID would do
+    <braunr> antrik: yes but i was wondering what kdb would actually show
+    <antrik> I just realised that it would be useful for debugging accross
+      subhurds or kernel/userspace if some kind of unique task IDs could be
+      shown in ps output
+    <braunr> yes
+    <braunr> this requires some thought though
+    <braunr> ps shouldn't show that
+    <braunr> there should be mach specific commands i suppose
+    <braunr> but then, gdb and other tools wouldn't have access to subhurd
+      tasks either
+    <antrik> why shouldn't ps show that? I don't think it's any more sensitive
+      information than all the other stuff ps shows...
+    <braunr> it doesn't feel right
+    <braunr> i would want my system instances to be truely isolated
+    <braunr> and use special "cross instance" facilities
+    <braunr> when necessary
+    <antrik> that's completely orthogonal to what I'm talking about
+    <braunr> like eth-multiplexer
+    <braunr> you seem to be talking about security
+    <braunr> or privacy
+    <antrik> we discussed such options when zhengda worked on rootless subhurd
+    <antrik> no, I'm talking about convenient debugging
+    <braunr> right
+    <braunr> i don't think it'zs orthogonal here
+    <braunr> if we increase separation, it becomes less convenient
+    <antrik> for debugging purposes you would *not* use the isolation options
+    <braunr> ok so you propose two modes of operations
+    <antrik> BTW, as an isolated subhurd relies on the parent, it makes no
+      sense to hide subhurd tasks from the parent hurd -- only hide parent hurd
+      task from the subhurd
+    <braunr> agreed
+    <antrik> so even with an isolated subhurd global task IDs would still be
+      useful
+
+
+# IRC, freenode, #hurd, 2012-08-06
+
+    <braunr> antrik: if i'm right, the root file system executable is read from
+      the parent, right ?
+    <antrik> braunr: probably... I'm not sure about that part
+    <braunr> antrik: i've installed the same packages in both the main and
+      subhurds to be sure
+    <braunr> and to have the right binary and debugging symbols in gdb anyway
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index d504b41f..37f4e8bc 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -93,6 +93,8 @@ The [[concept|concepts]] of translators creates its own problems, too:
 * [[magic]]
 * [[unionfs]]
 * [[nfs]]
+* [[symlink]]
+* [[firmlink]]
 * ...
 
 
diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn
index 8e15d1c7..13a1d9ec 100644
--- a/hurd/translator/ext2fs.mdwn
+++ b/hurd/translator/ext2fs.mdwn
@@ -20,6 +20,8 @@ License|/fdl]]."]]"""]]
 
   * [[metadata_caching]]
 
+  * [[internal_allocator]]
+
 
 ## Large Stores
 
@@ -87,6 +89,20 @@ small backend stores, like floppy devices.
     <youpi> which can be quite probable
 
 
+## Sync Interval
+
+[[!tag open_issue_hurd]]
+
+
+### IRC, freenode, #hurd, 2012-10-08
+
+    <braunr> btw, how about we increase our ext2 sync interval to 30 seconds,
+      like others do ?
+    <braunr> not really because others do it that way, but because it severely
+      breaks performance on the hurd
+    <braunr> and 30 seems like a reasonable amount (better than 5 at least)
+
+
 # Documentation
 
   * <http://e2fsprogs.sourceforge.net/ext2.html>
diff --git a/hurd/translator/ext2fs/internal_allocator.mdwn b/hurd/translator/ext2fs/internal_allocator.mdwn
new file mode 100644
index 00000000..f3678a28
--- /dev/null
+++ b/hurd/translator/ext2fs/internal_allocator.mdwn
@@ -0,0 +1,39 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2012-07-30
+
+    <mcsim> Why for big buffers in ext2fs used own allocator, that just
+      allocates many pages at once, instead of using malloc?
+    <mcsim> i.e. can I replace it with malloc, because it just complicates
+      things?
+    <braunr> mcsim: probably because of alignment
+    <braunr> what gets complicated by that ?
+    <mcsim> braunr: than valloc?
+    <mcsim> braunr: this allocator allows to allocate only buffer with size of
+      vm_page_size.
+    <mcsim> valloc just would be clearer.
+    <braunr> valloc ?
+    <braunr> valloc is obsolete
+    <mcsim> braunr: than memalign or posix_memalign?
+    <mcsim> memalign obsolete too... would posix_memalign be eligible?
+    <braunr> mcsim: why memalign instead of the custom allocator ?
+    <mcsim> because, I think, it is clearer. Also, since I need to allocate any
+      amount of pages, not just one, I have to edit custom allocator. Although
+      it is not hard, but using ready stuff seems more sane for me.
+    <mcsim> braunr: ^
+    <braunr> right, but make sure posix_memalign doesn't create too much
+      overhead
+    <mcsim> braunr: what kind of overhead?
+    <braunr> fragmentation
+    <braunr> i assume the glibc implementation is careful about that, but still
diff --git a/hurd/translator/firmlink.mdwn b/hurd/translator/firmlink.mdwn
new file mode 100644
index 00000000..038879db
--- /dev/null
+++ b/hurd/translator/firmlink.mdwn
@@ -0,0 +1,22 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2012-07-20
+
+    <infinity0> does hurd have equivalent of mount --bind yet?
+    <kilobug> infinity0: unionfs with just one back-end ?
+    <infinity0> ah cool i'll try thaty
+    <kilobug> there may be something better, but that's the one I know about ;)
+    <braunr> infinity0: firmlinks
+    <infinity0> ah thanks i'll look that up
+    <kilobug> braunr: oh, true, I forgot about that one
diff --git a/hurd/translator/nfs.mdwn b/hurd/translator/nfs.mdwn
index bf24370a..81372204 100644
--- a/hurd/translator/nfs.mdwn
+++ b/hurd/translator/nfs.mdwn
@@ -10,6 +10,11 @@ License|/fdl]]."]]"""]]
 
 Translator acting as a NFS client.
 
+Only NFSv2/v3 is currentl supported.
+
+[[!tag open_issue_hurd]]There are a few unmerged changes on a former GSoC
+project's topic-branch.
+
 
 # See Also
 
diff --git a/hurd/translator/pfinet/ipv6.mdwn b/hurd/translator/pfinet/ipv6.mdwn
index 5afee0c6..d30cc850 100644
--- a/hurd/translator/pfinet/ipv6.mdwn
+++ b/hurd/translator/pfinet/ipv6.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2007, 2008, 2010, 2012 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]]."]]"""]]
 
 [[Stefan_Siegl|stesie]] has added IPv6 support to the pfinet [[translator]].
 This was [Savannah task #5470](http://savannah.gnu.org/task/?5470).
@@ -55,3 +55,18 @@ Quite the same, but with static IPv6 address assignment:
 # Missing Functionality
 
 Amongst other things, support for [[IOCTL]]s is missing.
+
+
+## IRC, freenode, #hurd, 2012-12-10
+
+[[!tag open_issue_hurd]]
+
+    <braunr> looks like pfinet -G option doesn't work
+    <braunr> if someone is interested in fixing this (it concerns static IPv6
+      routing)
+    <braunr> youpi: have you ever successfully used pfinet with global
+      statically configured ipv6 addresses ?
+    <youpi> never tried
+    <braunr> ok
+    <braunr> i'd like to set this up on my VMs but it looks bugged :/
+    <braunr> i can't manage to set correctly set the gateway
diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn
index 4f6492ed..8ee34949 100644
--- a/hurd/translator/procfs/jkoenig/discussion.mdwn
+++ b/hurd/translator/procfs/jkoenig/discussion.mdwn
@@ -278,6 +278,9 @@ Needed by glibc's `pldd` tool (commit
 
 # `/proc/[PID]/maps`
 
+[[!tag GNU_Savannah_bug 32770]]
+
+
 ## IRC, OFTC, #debian-hurd, 2012-06-20
 
     <pinotree> bdefreese: the two elfutils tests fail because there are no
@@ -313,3 +316,23 @@ Needed by glibc's `pldd` tool (commit
 
     * pinotree has a local work to add the /proc/$pid/cwd symlink, but relying
         on "internal" (but exported) glibc functions
+
+
+# "Unusual" PIDs
+
+Not actually related to procfs, but here seems to be a convenient place for
+filing these:
+
+
+## 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