IRC.

14 files changed, 696 insertions, 65 deletions

diff --git a/open_issues/bpf.mdwn b/open_issues/bpf.mdwn
index 2a8c897a..e24d761b 100644
--- a/open_issues/bpf.mdwn
+++ b/open_issues/bpf.mdwn
@@ -562,3 +562,26 @@ This is a collection of resources concerning *Berkeley Packet Filter*s.
       DDE accordingly
     <braunr> antrik: i agree
     <braunr> antrik: eth-multiplexer would be the right place
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <gnu_srs> braunr: Is  BPF fully supported by now? Can it be used for
+      isc-dhcp?
+    <braunr> gnu_srs: bpf isn't supported at all
+    <braunr> gnu_srs: instead of emulating it, i added a hurd-specific module
+      in libpcap
+    <braunr> if isc-dhcp can use libpcap, then fine
+    <braunr> (otherwise we could create a hurd-specific patch for dhcp that
+      uses the in-kernel bpf filter implementation)
+    <braunr> gnu_srs: can't it use a raw socket ?
+    <youpi> it can
+    <youpi> it's just that the shape of the patch to do so wasn't exactly how
+      they needed it
+    <youpi> so they have to rework it a bit
+    <youpi> and that takes time
+    <braunr> ok
+    <braunr> antrik: for now, we prefer encapsulating the system specific code
+      in libpcap, and let users of that library benefit from it
+    <braunr> instead of implementing the low level bpf interface, which
+      nonetheless has some system-specific variants ..
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index b15c880a..26fa6012 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -202,11 +202,59 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14
     `CLOCK_REALTIME_ALARM`, `O_PATH`,
     `PTRACE_*` (for example, cbff0d9689c4d68578b6a4f0a17807232506ea27),
     `RLIMIT_RTTIME`, `SEEK_DATA` (`unistd.h`), `SEEK_HOLE` (`unistd.h`)
-    `clock_adjtime`, `fallocate`, `fallocate64`, `getcontext` (and
-    `setcontext`), `name_to_handle_at`, `open_by_handle_at`,
-    `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
+    `clock_adjtime`, `fallocate`, `fallocate64`, `name_to_handle_at`,
+    `open_by_handle_at`, `process_vm_readv`, `process_vm_writev`, `sendmmsg`,
     `setns`, `sync_file_range`
 
+      * `getcontext`/`setcontext`
+
+        Needed for [[gccgo]].
+
+        IRC, freenode, #hurd, 2012-04-19:
+
+            <gnu_srs> How much work/knowledge is needed to implement
+              getcontext/setcontext?
+            <gnu_srs> Any already implemented alternatives available?
+            <youpi> x86 registers knowledge, as well as unix signal masks
+            <youpi> there's the linux implementation that can be taken as an
+              exxample, but the signal part has to be rewritten
+            <gnu_srs> Well, it's a pity they are not implemented. That's the
+              remaining hurdle to get gccgo working :-( 
+            <youpi> uh :/
+            <gnu_srs> Everything builds, but the testsuite fails due to these
+              missing functions.
+            <gnu_srs> Regarding getcontext/setcontext they seem to be written
+              in assembly for linux but the code is not very long. 
+            <gnu_srs> How much effort would it be to write something similar
+              for Hurd? Anybody fluent in asm?
+            <gnu_srs> And registers and signals.
+            <tschwinge> gnu_srs: Signals is the key thing -- everything else we
+              can probably just copy.  I have never/not yet looked at it,
+              though.
+            <gnu_srs> For kfreebsd it is written in C: kern_context.c, 3/4 in
+              one file: getcontext, setcontext,  swapcontext, not makecontext.
+            <gnu_srs> Dunno how much assembly calls used though.
+            <gnu_srs> Hi, any preferences about implementing get/setcontext in
+              C or Asm?
+            <tschwinge> gnu_srs: I think these will have to be implemented in
+              assembly.  Based on the Linux x86 variants.
+
+        IRC, freenode, #hurd, 2012-04-20:
+
+            <tschwinge> youpi: Your understanding of that is better than mine
+              -- the *context stuff can't be very useful at the moment, because
+              when the user changes uc_stack.ss_sp (which the glibc tests are
+              doing), we're losing access to the _hurd_threadvars.  Correct?
+            <tschwinge> At least the getcontext test works, the other get a
+              SIGILL.
+            <tschwinge> others
+            <tschwinge> _hurd_threadvars issue is just guessing.
+            <youpi> tschwinge: yes, threadvars are on the stack
+            <youpi> threadvars is not much code, it should just work, but care
+              has to be taken on the libpthread/libthread side, which does some
+              initialization
+            <tschwinge> OK, that at least matches my understanding.
+
       * `syncfs`
 
         We should be easily able to implement that one.
@@ -264,6 +312,35 @@ Last reviewed up to the [[Git mirror's d40c5d54cb551acba4ef1617464760c5b3d41a14
 
       * `timespec_get` (74033a2507841cf077e31221de2481ff30b43d51)
 
+      * `waitflags.h` (`WEXITED`, `WNOWAIT`, `WSTOPPED`, `WCONTINUED`)
+
+        IRC, freenode, #hurd, 2012-04-20:
+
+            <pinotree> in glibc, we use the generic waitflags.h which, unlike
+              linux's version, does not define WEXITED, WNOWAIT, WSTOPPED,
+              WCONTINUED
+            <pinotree> should the generic bits/waitflags.h define them anyway,
+              since they are posix?
+            <youpi> well, we'd have to implement them anyway
+            <youpi> but otherwise, I'd say yes
+            <pinotree> sure, but since glibc headers should expose at least
+              everything declared by posix, i thought they should be defined
+              anyway
+            <youpi> that might bring bugs
+            <youpi> some applications might be #ifdefing them
+            <youpi> and break when they are defined but not working
+            <pinotree> i guess they would define them to 0, andd having them to
+              non-zero values shouldn't break them (since those values don't do
+              anything, so they would act as if they were 0.. or not?)
+            <youpi> no, I mean they would do something else, not define them to
+              0
+            <pinotree> like posix/tst-waitid.c, you mean?
+            <youpi> yes
+
+    For specific packages:
+
+      * [[octave]]
+
   * Create `t/cleanup_kernel-features.h`.
 
   * Add tests from Linux kernel commit messages for `t/dup3` et al.
diff --git a/open_issues/glibc/getlogin_r.mdwn b/open_issues/glibc/getlogin_r.mdwn
new file mode 100644
index 00000000..9980ea1f
--- /dev/null
+++ b/open_issues/glibc/getlogin_r.mdwn
@@ -0,0 +1,45 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="getlogin_r"]]
+
+[[!tag open_issue_glibc]]
+
+
+# IRC, freenode, #hurd, 2012-04-23
+
+    * pinotree spots how our getlogin_r() implementation uses a static
+        buffer...
+    <braunr> oO
+    <pinotree> braunr: yeah, the _r means "reentrantbutnotreally" xD
+    <braunr> pinotree: that's amazing ..
+    <antrik> pinotree: without having checked the actual implementation, that
+      doesn't sound like a problem...
+    <antrik> caching doesn't break reentrancy. the problem with the plain
+      getlogin() is that a static buffer is *returned to the user*
+    <pinotree> antrik: http://paste.debian.net/164727/
+    <braunr> ah, caching
+    <pinotree> i don't think this is caching at all
+    <antrik> pinotree: OK, not actually caching... but same effect as far as I
+      can tell
+    <antrik> pinotree: or is it the fixed size of the temporary variable you
+      are concerned about?
+    <pinotree> antrik: my concern was about the "static" of the buffer used for
+      the get_login rpc
+    <antrik> pinotree: I'm not sure that's a problem. can the login actually
+      ever change for a running process?
+    <pinotree> dunno
+    <pinotree> but if so, it would be pointless to do the rpc every time
+      instead of just once
+    <antrik> pinotree: true
+    * pinotree would just make it non-static and be safe
+    <antrik> pinotree: well, one might argue that allocating a KiB of stack
+      space is not very friendly, especially in a low-level library...
+    <antrik> not sure what the general policy is about such things in libc
diff --git a/open_issues/glibc/octave.mdwn b/open_issues/glibc/octave.mdwn
new file mode 100644
index 00000000..b12b7558
--- /dev/null
+++ b/open_issues/glibc/octave.mdwn
@@ -0,0 +1,35 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_glibc]]
+
+
+# IRC, OFTC, #debian-hurd, 2012-04-23
+
+    <pinotree> diffing the octave i386 vs hurd-i386 build logs gives
+      interesting surprises
+    <youpi>   checking whether this system has an arbitrary file name length
+      limit... no              |  checking whether this system has an arbitrary
+      file name length limit... yes
+    <youpi> ?
+    <pinotree> not only that
+    <youpi>   checking whether getcwd handles long file names properly... yes
+      |  checking whether getcwd handles long file names properly... no, but it
+      is partly worki+
+    <youpi> ?
+    <pinotree> -checking whether fdopendir works... yes
+    <pinotree> +checking whether fdopendir works... no
+    <pinotree> (- is i386, + is hurd-i386)
+    <pinotree> -checking whether getlogin_r works with small buffers... yes
+    <pinotree> +checking whether getlogin_r works with small buffers... no
+    <pinotree> -checking for working mkstemp... yes
+    <pinotree> +checking for working mkstemp... no
+    <pinotree> +checking for working nanosleep... no (mishandles large
+      arguments)
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index f8e27e62..9feb30c8 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -2116,3 +2116,20 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
       remember)
     <braunr> use "physical" instead of "real memory"
     <mcsim> braunr: thank you.
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <braunr> youpi: tschwinge: when the slab code was added, a few new files
+      made into gnumach that come from my git repo and are used in other
+      projects as well
+    <braunr> they're licensed under BSD upstream and GPL in gnumach, and though
+      it initially didn't disturb me, now it does
+    <braunr> i think i should fix this by leaving the original copyright and
+      adding the GPL on top
+    <youpi> sure, submit a patch
+    <braunr> hm i have direct commit acces if im right
+    <youpi> then fix it :)
+    <braunr> do you want to review ?
+    <youpi> I don't think there is any need to
+    <braunr> ok
diff --git a/open_issues/gnumach_page_cache_policy.mdwn b/open_issues/gnumach_page_cache_policy.mdwn
new file mode 100644
index 00000000..75fcdd88
--- /dev/null
+++ b/open_issues/gnumach_page_cache_policy.mdwn
@@ -0,0 +1,35 @@
+[[!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_gnumach]]
+
+
+# IRC, freenode, #hurd, 2012-04-26
+
+    <braunr> another not-too-long improvement would be changing the page cache
+      policy
+    <youpi> to drop the 4000 objects limit, you mean ?
+    <braunr> yes
+    <youpi> do you still have my patch attempt ?
+    <braunr> no
+    <youpi> let me grab that
+    <braunr> oh i won't start it right away you know
+    <braunr> i'll ask for it when i do
+    <youpi> k
+    <braunr> (otherwise i fell i'll just loose it again eh)
+    <youpi> :)
+    <braunr> but i imagine it's not too hard to achieve
+    <youpi> yes
+    <braunr> i also imagine to set a large threshold of free pages to avoid
+      deadlocks
+    <braunr> which will still be better than the current situation where we
+      have either lots of free pages because tha max limit is reached, or lots
+      of pressure and system freezes :/
+    <youpi> yes
diff --git a/open_issues/gnumach_vm_map_red-black_trees.mdwn b/open_issues/gnumach_vm_map_red-black_trees.mdwn
new file mode 100644
index 00000000..d77bea32
--- /dev/null
+++ b/open_issues/gnumach_vm_map_red-black_trees.mdwn
@@ -0,0 +1,142 @@
+[[!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_gnumach]]
+
+
+# IRC, freenode, #hurd, 2012-04-23
+
+    <braunr> btw, i'm running a gnumach version using red-black trees for vm
+      map entries
+    <antrik> braunr: sounds fashionable ;-)
+    <youpi> braunr: with some perf improvement?
+    <braunr> looks promising for our ext2fs instances showing several thousands
+      of map entries
+    <braunr> youpi: i'm not using it for lookups yet
+    <braunr> but the tree is there, maintained, used for both regular and copy
+      maps, and it doesn't crash
+    <youpi> good :)
+    <braunr> antrik: isn't it ? :)
+    <braunr> youpi: and the diff stat is like 50/15
+    <antrik> braunr: what's the goal of using the fashionable trees?
+    <braunr> antrik: speeding up lookups in address spaces
+    <antrik> braunr: so the idea is that if we have a heavily fragmented
+      address space, the performance penalty is smaller?
+    <braunr> yes
+    <antrik> OK
+    <antrik> I take it you gave up on attempts to actually decrease
+      fragmentation?...
+    <braunr> it's not as good as reducing fragmentation, which requires
+      implementing a powerful merge, but it's still better
+    <braunr> yes
+    <braunr> it's too messy for my brain :/
+    <antrik> I see
+    <antrik> oh
+    <braunr> it will add some overhead though
+    <youpi> I guess log(n) ?
+    <braunr> but if there is a significant performance gain, it'll be worth it
+    <braunr> yes
+    <braunr> i was more thinking about the memory overhead
+    <antrik> right now it's a linear list?
+    <youpi> I don't think we care nowadays :)
+    <braunr> antrik: yes
+    <antrik> ouch
+    <braunr> antrik: yes ... :>
+    <braunr> the original authors expected vm maps to have like 30 entries
+    <braunr> so they used a list for the maps, and a hash table for the
+      object/offset to physical page lookups
+    <braunr> there is a small lookup cache though, which is a nice optimization
+    <braunr> my code now uses it first, and falls back to the RB tree if the
+      hint didn't help
+    <antrik> braunr: well, don't forget to check whether it actually *is* still
+      an optimisation, when using fashionable trees ;-)
+    <braunr> antrik: i checked that already :)
+    <braunr> i did the same in x15
+    <antrik> I see
+    <braunr> both bsd and linux uses a similar technique
+    <braunr> use*
+    <braunr> (well, bsd actually use what is done in mach :)
+    <antrik> (or perhaps the other way around... ;-) )
+    <braunr> i don't think so, as the bsd vm is really the mach vm
+    <braunr> but we don't care much
+    <antrik> oh, right... that part actually went full circle
+    <braunr> youpi: i have a patch ready for test on machines with significant
+      amounts of map entries (e.g. the buildds ..)
+    <braunr> youpi: i won't have time for tests tonight, are you interested ?
+    <braunr> (i've been running it for 15 minutes without any issue for now)
+    <youpi> I'd say post to the list
+    <braunr> ok
+    <youpi> braunr: your patch uses the rb tree for lookups, right?
+    <youpi> braunr: the buildd using rbtree seems swift
+    <youpi> but maybe it's just a psychologic effect :)
+    <youpi> the chroot ext2fs already has 1392 lines in vminfo
+    <youpi> an rbtree can't hurt  there :)
+    <youpi> braunr: it really seems faster
+    <youpi> the reboot might have helped too
+    <youpi> benchmarks shall say
+    <youpi> for now, I'll just let ironforge use it
+    <antrik> youpi: it's always fast after a reboot ;-)
+    <youpi> sure
+    <youpi> but still
+    <youpi> I mean
+    <youpi> *obviously* the reboot has helped
+    <youpi> but it might not be all
+    <youpi> at least it feels so
+    <youpi> and obviously only benchmarks can say
+    <antrik> the major benefit AIUI is rather that the slowdown happening over
+      time will be less noticable
+
+[[performance/degradation]].
+
+    <youpi> "over time" is actually quite fast
+    <youpi> ext2 fills up very quickly when you build a package
+    <youpi> it went up to 1700 lines very quickly
+    <youpi> and stabilized around there
+    <antrik> yeah, it can be very fast under heavy load
+    <youpi> that's why I say reboot seems not all
+    <youpi> it's already not so fresh
+    <youpi> with 1700 lines in vminfo
+    <antrik> well, I don't know how much of the slowdown I'm experiencing
+      (after doing stuff under memory pressure) is actually related to VM map
+      fragmentation...
+    <antrik> might be all, might be none, might be something in between
+    <youpi> then try his patch
+    <antrik> guess I should play a bit with vminfo...
+    <antrik> well, currently I actually experience pretty little slowdown, as
+      for certain reasons (only indirectly related to the Hurd) I'm not running
+      mutt on this machine, so I don't really have memory pressure...
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <braunr> youpi: yes, it uses bst lookups
+    <braunr> youpi: FYI, the last time i checked, one ext2fs instance had 4k+
+      map entries, and another around 7.5k
+    <braunr> (on ironforge)
+
+
+## IRC, freenode, #hurd, 2012-04-24
+
+    <youpi> braunr: $ sudo vminfo  624 | wc -l
+    <youpi> 22957
+    <youpi> there's no way it can not help :)
+    <braunr> youpi: 23k, that's really huge
+
+
+## IRC, freenode, #hurd, 2012-04-26
+
+    <braunr> youpi: any new numbers wrt the rbtree patch ?
+    <youpi> well, buildd times are not really accurate :)
+    <youpi> but what I can tell is that it managed to build qtwebkit fine
+    <braunr> ok
+    <youpi> so the patch is probably safe :)
+    <braunr> i'll commit it soon then
+    <youpi> I'd say feel free to, yes
+    <braunr> thanks
diff --git a/open_issues/libpthread.mdwn b/open_issues/libpthread.mdwn
index 614f1271..c5054b7f 100644
--- a/open_issues/libpthread.mdwn
+++ b/open_issues/libpthread.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -25,43 +26,19 @@ There is a [[!FF_project 275]][[!tag bounty]] on this task.
 [[!inline pages=community/gsoc/project_ideas/pthreads feeds=no]]
 
 
+## IRC, freenode, #hurd, 2012-04-26
 
-# pthread/stubs issue w/ dlopen'ed libraries
+    <pinotree> youpi: just to be sure: even if libpthread is compiled inside
+      glibc (with proper symbols forwarding etc), it doesn't change that you
+      cannot use both cthreads and pthreads in the same app, right?
 
-IRC, freenode, #hurd, 2010-01-24
+[[Packaging_libpthread]].
 
-    <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
-      libraries
-    <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
-      we're the only one with such configuration
-    <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it
-      be it does not set THREADLIBS in the configure.ac switch case?
-    <youpi> that's expected
-    <youpi> on linux the libc provides hooks itself, on hurd-i386 it's
-      pthread-stubs
-    <pinotree> why not explicitly link to pthread though?
-    <youpi> because there is no strict need to, for applications that don't
-      need libpthread
-    <youpi> the dlopen case is a tricky case that pthread-stubs had not thought
-      about
-    <pinotree> hm
-    <pinotree> what if the pthread stubs would be moved in our glibc?
-    <youpi> that's what we should do yes
-    <youpi> (ideally)
-    <youpi> but for this we need to build libpthread along glibc, to get it
-      really working
-    <youpi> and that's the tricky part (Makefile & such) which hasn't been done
-      yet
-    <pinotree> why both (stubs + actual libpthread)?
-    <youpi> because you need the stubs to be able to call the actual libpthread
-    <youpi> as soon libpthread gets dlopened for instance
-    <youpi> +as
-    <pinotree> i see
-    <youpi> (remember that nptl does this if you want to see how)
-    <youpi> (it's the libc files in nptl/)
-    <youpi> (and forward.c)
-    <guillem> also if libpthreads gets integrated with glibc don't we need to
-      switch the hurd from cthreads then? Which has been the blocker all this
-      time AFAIR?
-    <youpi> we don't _need_ to
-    <guillem> ok
+    <youpi> it's the same libpthread
+    <youpi> symbol forwarding does not magically resolve that libpthread lacks
+      some libthread features :)
+    <pinotree> i know, i was referring about the clash between actively using
+      both
+    <youpi> there'll still be the issue that only one will be initialized
+    <youpi> and one that provides libc thread safety functions, etc.
+    <pinotree> that's what i wanted to knew, thanks :)
diff --git a/open_issues/libpthread_CLOCK_MONOTONIC.mdwn b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
new file mode 100644
index 00000000..f9195540
--- /dev/null
+++ b/open_issues/libpthread_CLOCK_MONOTONIC.mdwn
@@ -0,0 +1,58 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="libpthread: CLOCK_MONOTONIC"]]
+
+[[!tag open_issue_glibc open_issue_libpthread]]
+
+[[!message-id "201204220058.37328.toscano.pino@tiscali.it"]]
+
+
+# IRC, freenode, #hurd- 2012-04-22
+
+    <pinotree> youpi: what i thought would be creating a
+      glib/hurd/hurdtime.{c,h}, adding _hurd_gettimeofday and
+      _hurd_clock_{gettime,settime,getres} to it and making the current .c in
+      sysdeps call those
+    <youpi> yep
+    <youpi> that's unfortunate, but that's what nptl actually does
+    <pinotree> this way we could add inside hurdtime.c the mapped time stuff
+      too
+    <pinotree> most probably a noobish question, but why does rt link to
+      pthread?
+    <youpi> no idea :)
+    <youpi> possibly due to aio implementation
+    <youpi> ./sysdeps/pthread/aio_cancel.c
+    <youpi> probably due to that
+    <youpi> (and others)
+
+
+## IRC, freenode, #hurd- 2012-04-23
+
+    <youpi> pinotree: about librt vs libpthread, don't worry too much for now
+    <youpi> libpthread can lib against the already-installed librt
+    <youpi> it does work
+    <pinotree> youpi: wouldn't that cause a dependency loop?
+    <youpi> pinotree: what dependency loop?
+    <pinotree> youpi: librt wouldd link to pthread, no?
+    <youpi> and ?
+    <youpi> I don't think it's an issue that .so link with each other
+    <pinotree> it isn't?
+    <youpi> well, try
+    * pinotree never did that
+    <youpi> but I don't think it will pose problem
+    <youpi> well, perhaps initialization order
+    <youpi> anyway, I now have packages built, I'll test that
+    <youpi> pinotree: ok, it seems it doesn't work indeed :)
+    <youpi> early in initialization
+    <youpi> pinotree: the initialization bug might actually not be due to librt
+      at all
+    <youpi> pinotree: yes, things work even with -lrt
+    <pinotree> wow
diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn
index fb665c67..05a07ef2 100644
--- a/open_issues/libpthread_dlopen.mdwn
+++ b/open_issues/libpthread_dlopen.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
@@ -10,7 +10,52 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_libpthread]]
 
-IRC, OFTC, #debian-hurd, 2011-07-21.
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2010-01-24
+
+    <pinotree> youpi: hm, thought about the pthread/stubs issue w/ dlopen'ed
+      libraries
+    <pinotree> currently looks like libstdc++ on hurd links to pthread-stubs,
+      we're the only one with such configuration
+    <pinotree> i was looking at the gcc 4.4 patch hurd-pthread.diff, could it
+      be it does not set THREADLIBS in the configure.ac switch case?
+    <youpi> that's expected
+    <youpi> on linux the libc provides hooks itself, on hurd-i386 it's
+      pthread-stubs
+    <pinotree> why not explicitly link to pthread though?
+    <youpi> because there is no strict need to, for applications that don't
+      need libpthread
+    <youpi> the dlopen case is a tricky case that pthread-stubs had not thought
+      about
+    <pinotree> hm
+    <pinotree> what if the pthread stubs would be moved in our glibc?
+    <youpi> that's what we should do yes
+    <youpi> (ideally)
+    <youpi> but for this we need to build libpthread along glibc, to get it
+      really working
+
+[[Packaging_libpthread]].
+
+    <youpi> and that's the tricky part (Makefile & such) which hasn't been done
+      yet
+    <pinotree> why both (stubs + actual libpthread)?
+    <youpi> because you need the stubs to be able to call the actual libpthread
+    <youpi> as soon libpthread gets dlopened for instance
+    <youpi> +as
+    <pinotree> i see
+    <youpi> (remember that nptl does this if you want to see how)
+    <youpi> (it's the libc files in nptl/)
+    <youpi> (and forward.c)
+    <guillem> also if libpthreads gets integrated with glibc don't we need to
+      switch the hurd from cthreads then? Which has been the blocker all this
+      time AFAIR?
+    <youpi> we don't _need_ to
+    <guillem> ok
+
+
+# IRC, OFTC, #debian-hurd, 2011-07-21
 
     <youpi> there's one known issue with pthreads
     <youpi> you can't dlopen() it
diff --git a/open_issues/o_exec.mdwn b/open_issues/o_exec.mdwn
new file mode 100644
index 00000000..3f77a0f2
--- /dev/null
+++ b/open_issues/o_exec.mdwn
@@ -0,0 +1,54 @@
+[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!meta title="O_EXEC"]]
+
+[[!tag open_issue_glibc open_issue_hurd]]
+
+
+# IRC, freenode, #hurd, 2012-04-24
+
+    <pinotree> interesting, glibc on every OS except hurd (so including linux
+      too) does not define O_EXEC
+    <pinotree> can somebody please help me understand a POSIX behaviour?
+    <pinotree> it's about fexecve:
+      http://pubs.opengroup.org/onlinepubs/9699919799/functions/fexecve.html
+    <pinotree> basically, it seems to me (reading the "errors" and "application
+      usage" sections) that O_EXEC for open() the fd is not mandatory, and if
+      not used fexecve will check for file permission at call time?
+    <pinotree> because currently libdiskfs and libnetfs require the fd to be
+      open with O_EXEC
+    <braunr> "Since execute permission is checked by fexecve(), the file
+      description fd need not have been opened with the O_EXEC flag"
+    <braunr> this one makes it clear checking for O_EXEC is wrong
+    <braunr> it looks like O_EXEC is only needed when you want to have files
+      for which only the execution permission is set
+    <braunr> but not the read one
+    <braunr> (i don't understand the "and write" part though)
+    <braunr> "exec will fail if the mode of the file associated with fd does
+      not grant execute permission to the calling process at the time fexecve()
+      is called."
+    <braunr> this one strengthens the impression you have, that fexecve indeed
+      checks file permissions at the time it's called
+    <braunr> pinotree: hope it helps
+    <pinotree> so it implies the following:
+    <pinotree> O_RDONLY → exec works if the file is readable
+    <braunr> exec works if the file is readable and/or executable (although
+      without read permissions you can't check it)
+    <braunr> (well, fexecve)
+    <pinotree> O_EXEC → exec requires that the permission of the file at
+      fexecve() time have +x
+    <braunr> i'd say ye so far
+    <braunr> yes
+    <pinotree> so we need to fix lib{disk,net}fs then
+    <braunr> seems so
+    <pinotree> enlighting, merci braunr 
+    <braunr> de rien
+    <pinotree> :)
diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn
index fa3d4312..f8ef4ae7 100644
--- a/open_issues/packaging_libpthread.mdwn
+++ b/open_issues/packaging_libpthread.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 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
@@ -10,9 +11,13 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_libpthread open_issue_glibc]]
 
-IRC, #hurd, 2010-07-31
+[[!toc]]
 
-    <tschwinge> My idea was to have a separate libpthread package.  What do you think about that?
+
+# IRC, freenode, #hurd, 2010-07-31
+
+    <tschwinge> My idea was to have a separate libpthread package.  What do you
+      think about that?
     <youpi> in the long term, that can't work with glibc
     <youpi> because of the thread stub stuff
 
@@ -21,30 +26,103 @@ IRC, #hurd, 2010-07-31
     <youpi> it's not really possible to keep synchronized
     <youpi> because you have to decide which package you unpack first
     <youpi> (when upgrading)
-    <tschwinge> Hmm, how is that different if two shared libraries are in one package vs. two packages?  It isn't atomic either way?  Aren't sonames / versioned library packages solving that?
+    <tschwinge> Hmm, how is that different if two shared libraries are in one
+      package vs. two packages?  It isn't atomic either way?  Aren't sonames /
+      versioned library packages solving that?
     <tschwinge> ... for incompatible forward changes?
     <youpi> that'd be a mess to maintain
-    <youpi> Drepper doesn't have this constraint and thus adds members of private fields at will
-    <tschwinge> OK, but how is it different then if the libpthread is in the Hurd package?
+    <youpi> Drepper doesn't have this constraint and thus adds members of
+      private fields at will
+    <tschwinge> OK, but how is it different then if the libpthread is in the
+      Hurd package?
     <youpi> I'm not saying it's better to have libpthread in the Hurd package
     <tschwinge> OK.
-    <youpi> I'm saying it's useless to package it separately when Drepper makes everything to have us put it along glibc
+    <youpi> I'm saying it's useless to package it separately when Drepper makes
+      everything to have us put it along glibc
     <tschwinge> Then, to goal is to have it in glibc?
     <tschwinge> OK.   :-)
-    <tschwinge> OK, I can accommodate to that.  Isn't not that we'd want to switch libpthread to something else so quickly.
-    <tschwinge> So our official goal is to have libpthread in glibc, at least for Debian purposese?
+    <tschwinge> OK, I can accommodate to that.  Isn't not that we'd want to
+      switch libpthread to something else so quickly.
+    <tschwinge> So our official goal is to have libpthread in glibc, at least
+      for Debian purposese?
     <youpi> for any port purpose
     <tschwinge> Ack.
-    <youpi> provided you're using glibc, you're deemed to ship libpthread with it
+    <youpi> provided you're using glibc, you're deemed to ship libpthread with
+      it
     <youpi> because of the strong relations Drepper puts between them
-    <youpi> (just to remind: we already have bugs just because our current libpthread isn't bound enough to glibc: dlopen()ing a library depending on libpthread doesn't work, for instance)
-    <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread isn't used
+    <youpi> (just to remind: we already have bugs just because our current
+      libpthread isn't bound enough to glibc: dlopen()ing a library depending
+      on libpthread doesn't work, for instance)
+    <pinotree> yeah, pthread-stubs is linked to almost everywhere -lpthread
+      isn't used
     <pinotree> (would be nice to not have those issues anymore...)
-    <tschwinge> So -- what do we need to put it into glibc?  We can make libpthread a Git submodule (or move the code; but it's shared also for Neal's viengoos, so perhaps the submodule is better?), plus some glibc make foo, plus some other adaptions (stubs, etc.)
-    <tschwinge> Does that sound about right, or am I missing something fundamental?
+    <tschwinge> So -- what do we need to put it into glibc?  We can make
+      libpthread a Git submodule (or move the code; but it's shared also for
+      Neal's viengoos, so perhaps the submodule is better?), plus some glibc
+      make foo, plus some other adaptions (stubs, etc.)
+    <tschwinge> Does that sound about right, or am I missing something
+      fundamental?
     <youpi> I actually don't know what a git submodule permits :)
     <youpi> looks like a good thing for this, yes
-    <tschwinge> Unfortunately I can't allocate much time at the moment to work on this.  :-/
-    <youpi> well, as long as I know where we're going, I can know how to package stuff in Debian
-    <tschwinge> That sounds like a plan to me.  libpthread -> glibc as submodule.
-    <youpi> (note: actually, the interface between glibc and the libpthread is the responsibility of the libpthread: it gives a couple of .c files to be shipped in libc.so)
+    <tschwinge> Unfortunately I can't allocate much time at the moment to work
+      on this.  :-/
+    <youpi> well, as long as I know where we're going, I can know how to
+      package stuff in Debian
+    <tschwinge> That sounds like a plan to me.  libpthread -> glibc as
+      submodule.
+    <youpi> (note: actually, the interface between glibc and the libpthread is
+      the responsibility of the libpthread: it gives a couple of .c files to be
+      shipped in libc.so)
+
+
+# IRC, freenode, #hurd, 2012-04-21
+
+    <youpi> had you tried to build libpthread as a glibc addon?
+    <tschwinge> youpi: No, I only know about libpthread in Hurd build system,
+      and libpthread stand-alone (with the Auto* stuff that I added), but not
+      yet as a glibc add-on.
+    <youpi> k
+    <youpi> I'm trying it atm
+    <tschwinge> Oh, OK.
+    <youpi> that should fix the no-add-needed issue in gcc/binutils, as well as
+      the pthread_threads assertion errors in threaded plugins
+    <youpi> (once I add forward.c, but that part should not be hard)
+    <pinotree> that means also less use of pthread-stubs^
+    <pinotree> ?
+    <youpi> tschwinge: do you remember whether sysdeps/mach/bits/spin* are used
+      by anybody?
+    <youpi> they are half-finished (no __PTHREAD_SPIN_LOCK_INITIALIZER), and
+      come in the way when building in glibc
+    <youpi> also, any reason for using ia32 and not i386? glibc uses the latter
+    <youpi> pinotree: rid of pthread-stubs yes
+    <pinotree> \o/
+    <tschwinge> youpi: You mean sysdeps/mach/i386/machine-lock.h?  No idea
+      about that one, sorry.
+    <youpi> I'm talking about libpthread
+    <youpi> not glibc
+    <tschwinge> Oh.
+    <tschwinge> sysdeps/ia32/bits/spin-lock.h:# define
+      __PTHREAD_SPIN_LOCK_INITIALIZER ((__pthread_spinlock_t) 0)
+    <tschwinge> Anyway, no idea about that either.
+    <youpi> that one is meant to be used with the spin-lock.h just below
+    <youpi> +-inline
+    <youpi> also, I guess signal/ was for the l4 port?
+    <tschwinge> youpi: I guess so.
+    <youpi> tschwinge: I have an issue with sysdeps pt files:
+      sysdeps/hurd/pt-getspecific.c is not looked for by libc ; symlinking into
+      sysdeps/mach/hurd/pt-getspecific.c works
+    <youpi> we don't have a non-mach sysdeps directory?
+    <pinotree> youpi: if you add sysdeps/mach/hurd/Implies containing only
+      "hurd", does sysdeps/hurd work?
+    <youpi> ah, right
+    <pinotree> youpi: did it work? (and, it was needed in sysdeps/mach/hurd, or
+      in libpthread/sysdeps/mach/hurd?)
+    <youpi> pinotree: it worked, it was for libpthread
+    <youpi> good: I got libpthread built and forward working
+
+
+## IRC, freenode, #hurd, 2012-04-23
+
+    <youpi> phew
+    <youpi> confirmed that moving libpthread to glibc fixes the gcc/binutils
+      no-add-needed issue
diff --git a/open_issues/system_call_mechanism.mdwn b/open_issues/system_call_mechanism.mdwn
index 5598148c..68418097 100644
--- a/open_issues/system_call_mechanism.mdwn
+++ b/open_issues/system_call_mechanism.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
@@ -10,8 +10,47 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-05-07
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-05-07
 
     <braunr> very simple examples: system calls use old call gates, which are
       the slowest path to kernel space
     <braunr> modern processors have dedicated instructions now
+
+
+# IRC, freenode, #hurd, 2012-04-22
+
+    <braunr> rah: basically, system calls are slower on mach because they use
+      call gates instead of newer sysenter/sysexit
+    <youpi> braunr: sysenter/exit is a x86_64 thing
+    <braunr> rah: apart from that, the code can't get much simpler, and *I*
+      know, for i have studied it, and wrote a compatible version in a clone
+      attempt
+    <youpi> braunr: on a x86_64 port we'd probably use sysenter/exit
+    <braunr> youpi: no there are 32-bits instructions, i don't remember if
+      they're called sysenter, it's in my thesis though so i'm sure of it :)
+    <youpi> braunr: ah, the other part
+    <youpi> is linux-x86 using them?
+    <braunr> youpi: yes, glibc uses them
+    <youpi> and does it really change much nowadays?
+    <youpi> what is the actual difference between int 80 and sysenter?
+    <braunr> less checking
+    <youpi> checking what?
+    <youpi> the idt?
+    <braunr> ring levels for example
+    <youpi> well, checking a ring is fast :)
+    <braunr> depending on the original and requested levels, there are lookups
+      in tables
+    <braunr> sysenter always assume 3 to 0 and 0 to 3 for sysexit
+    <youpi> ah, also it assumes things about segments
+    <youpi> so that indeed makes context things simpler
+    <braunr> right
+    <braunr> but mach doesn't uses int 0x80
+    <braunr> it uses an lcall
+    <braunr> which is a bit slower from what I could read some time ago
+    <braunr> (not sure if it's still relevant)
+    <youpi> actually in 64bit mode I had to catch lcall from the invalid
+      instruction trap
+    <youpi> perhaps it got dropped in 64bit mode
diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
index 70c3c6dc..25168fce 100644
--- a/open_issues/user-space_device_drivers.mdwn
+++ b/open_issues/user-space_device_drivers.mdwn
@@ -1,4 +1,5 @@
-[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 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
@@ -64,7 +65,7 @@ Also see [[device drivers and IO systems]].
 
 ## System Boot
 
-IRC, freenode, #hurd, 2011-07-27
+### IRC, freenode, #hurd, 2011-07-27
 
     < braunr> btw, was there any formulation of the modifications required to
       have disk drivers in userspace ?
@@ -88,6 +89,11 @@ IRC, freenode, #hurd, 2011-07-27
     < Tekk_> mhm
     < braunr> s/disk/storage/
 
+### IRC, freenode, #hurd, 2012-04-25
+
+    <youpi> btw, remember the initrd thing?
+    <youpi> I just came across task.c in libstore/ :)
+
 
 # Plan