From 5a419f5931a7797e7f9e1909453cf1eba0c40e59 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Fri, 14 Oct 2011 21:22:37 +0200
Subject: open_issues/translator_stdout_stderr: Link to Thomas Bushnell email.

---
 open_issues/translator_stdout_stderr.mdwn | 8 +++++++-
 1 file changed, 7 insertions(+), 1 deletion(-)

(limited to 'open_issues')

diff --git a/open_issues/translator_stdout_stderr.mdwn b/open_issues/translator_stdout_stderr.mdwn
index e0828b28..11793582 100644
--- a/open_issues/translator_stdout_stderr.mdwn
+++ b/open_issues/translator_stdout_stderr.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation,
+[[!meta copyright="Copyright © 2008, 2009, 2010, 2011 Free Software Foundation,
 Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -13,3 +13,9 @@ License|/fdl]]."]]"""]]
 
 Decide / implement / fix that (all?) running (passive?) translators' output
 should show up on the (Mach / Hurd) console / syslog.
+
+[[!taglink open_issue_documentation]]: [[!message-id
+"87oepj1wql.fsf@becket.becket.net"]]
+
+[[!taglink open_issue_documentation]]: Neal once had written an email on this
+topic.
-- 
cgit v1.2.3


From 080e7638c9c1b626b041594ca774bf4a7de4301f Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Sat, 15 Oct 2011 12:22:01 +0200
Subject: open_issues/glibc: t/init-first.c.

---
 open_issues/glibc.mdwn            | 16 ++++----
 open_issues/glibc_init_first.mdwn | 78 ---------------------------------------
 2 files changed, 7 insertions(+), 87 deletions(-)
 delete mode 100644 open_issues/glibc_init_first.mdwn

(limited to 'open_issues')

diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index be262261..e48dde9c 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -40,12 +40,12 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
         `t/dup3`: hidden def.  ed690b2f24bbc4d9c541fc81a7c67e6dc5678a96 -- why
         not for dup3, too?  Because it is a syscall (that is always inlined)?
 
-  * t/init-first.c
+  * `t/init-first.c`
 
-    Have to revert 53b56b1101fc9bb4f295f23f54e7e19f8da8da16 to keep it working
-    with GCC 4.4.  Figure out what's going on.  Also see [[glibc_init_first]].
-
-    There is a `RETURN_ADDRESS` macro in glibc.
+    Follow up here: [[!message-id "20070722171859.GN25744@fencepost.gnu.org"]]
+    or [[!message-id "87mxe4kwws.fsf@gnu.org"]].  Close [[!GNU_Savannah_bug
+    17647]].  Debian: [[!message-id "E1Qup1U-0006Zc-39@vasks.debian.org"]]
+    (part of Ludo's patch; the part that is not harmful to GCC 4.4).
 
   * `t/kernel-features.h_includes`
 
@@ -192,8 +192,6 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
         Need changes equivalent to c55fbd1ea768f9fdef34a01377702c0d72cbc213 +
         14d96785125abee5e9a49a1c3037f35a581750bd.
 
-  * Building with GCC 4.5, 4.6, trunk will cause different kinds of faults.
-
   * Create `t/cleanup_kernel-features.h`.
 
   * Add tests from Linux kernel commit messages for `t/dup3` et al.
@@ -371,7 +369,7 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
 # Build
 
 Here's a log of a glibc build run; this is from our [[Git repository's
-8cb1875ef1e3211ec133d8eea328dbe59538c2a7 (2011-10-11)
+0abded0927c62f02399658395837917548d5e281 (2011-10-14)
 sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
 
     $ export LC_ALL=C
@@ -383,7 +381,7 @@ sources|source_repositories/glibc]], run on coulomb.SCHWINGE.
 This takes up around 400 MiB and needs roughly 120 min on coulomb.SCHWINGE.
 
 <!--
-    $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check 2>&1 | tee log_check
+    $ (make install_root=/INVALID && touch .go-check) 2>&1 | tee log_build_ && test -f .go-check && make -k install_root=/INVALID check TIMEOUTFACTOR=100 2>&1 | tee log_check
     $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do ~/tmp/gcc/git/contrib/compare-debug --preserve ../Roger_Whittaker.build-gcc-4.4-486.O/"$f" "$f"; done 2>&1 | less 
     $ while read f; do (readelf -a "$f" && objdump -xDrtw "$f") > N && (cd ../Roger_Whittaker.build-gcc-4.4-486.O/ && readelf -a "$f" && objdump -xDrtw "$f") > O && diff -u O N | less; done
     $ find ./ -name \*.o -o -name \*.os -o -name \*.oS | while read f; do readelf -h "$f" | grep OS/ABI | (read a b && [ x"$b" != x'UNIX - System V' ] && echo "### $f: $b"); done
diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn
deleted file mode 100644
index 774b7828..00000000
--- a/open_issues/glibc_init_first.mdwn
+++ /dev/null
@@ -1,78 +0,0 @@
-[[!meta copyright="Copyright © 2011 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, freenode, #hurd, 2011-07-22
-
-    [additional init-first.c patch]
-    < tschwinge> civodul: The only thing I wonder about: Roland also once had
-      done similar changes, which I then found they didn'T work with GCC 4.1,
-      and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed
-      the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and
-      e17cef66140d4c97710ea88bd8d12612799e1e0f).  Have you reviewed this?
-    < tschwinge> That's in the Savannah glibc repository.
-    < tschwinge> And this has been in 2007, four years ago.  I don't remember
-      all the details.
-    < tschwinge> And here is quite a good summary of this stuff, from
-      init-first.c:
-    < tschwinge> /* XXX This is all a crock and I am not happy with it.
-    < tschwinge>    This poorly-named function is called by static-start.S,
-    < civodul> braunr: thanks; i must admit it took me a while to figure it out
-      ;-)
-    < tschwinge>    which should not exist at all.  */
-    < tschwinge> civodul: I can imagine...  :-/
-    < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to
-      reinstate his change and see if it works
-    < civodul> now, i won't test with GCC 4.1...
-    < tschwinge> Yeah...
-    < tschwinge> I'm happy if it works with 4.4 onwards.
-    < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void
-      **) __builtin_frame_address (0) + 1)'', and similar?
-    < tschwinge> Or should we be coding this few stuff in assembly?
-    < civodul> tschwinge: well, we should add a compile-time assertion for
-      __builtin_return_address (0) == *((void**)__builtin_frame_address (0) +
-      1)
-    < civodul> (i think GCC can figure it out at compile-time)
-    < civodul> but on IA32 it should always be true
-    < civodul> what's the name of glibc's compile-time assert macro already?
-    < tschwinge> I wonder whether that might interfere with some of GCC's
-      optimizations?
-    < civodul> what?
-    < tschwinge> Well, it seems unclean for me to be modifying a function's
-      return address from within C code.
-    < tschwinge> civodul: I added a verify.h in the t/verify.h branch.  But
-      people didn't really like it too much.  They rather wanted to directly
-      inline the array[(cond)?1:-1] code.
-    < civodul> ok
-    < civodul> i remember a debate about Gnulib's verify.h
-    < civodul> i thought something comparable had landed eventually
-    < tschwinge> civodul: Oh, maybe I missed it.
-    < tschwinge> civodul: In init-first.c:init, what about the usage of
-      data[-1] in the else path (not using cthreads) -- is that good as-is?
-    < civodul> tschwinge: oooh, it probably needs to fixed too
-    < civodul> but i haven't reached that point yet ;-)
-     * civodul tries to cross-bootstrap GNU from scratch
-    < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's
-      original idea of fixing this.  Or perhaps this was a GCC 4.1 bug?  Or
-      perhaps GCC was inlining to much, and then got confused with frames and
-      return addresses?
-    < civodul> tschwinge: Roland's change looks good to me, so it could have
-      been a GCC bug
-    < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both
-      data[-1] replaced)?
-    < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4
-      onwards.  If yes, please add your changelog snippet to .topmsg, and also
-      add a not that Roland's original code may in fact have been fine, and we
-      may have hit a compiler bug.
-    < civodul> tschwinge: OK, will do
-    < civodul> tschwinge: though regarding Roland's change, i'd prefer to
-      actually test and see
-    < tschwinge> civodul: Thanks!
-- 
cgit v1.2.3


From bb5dcd67e20957e035613a5a80d58cd4811713fc Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Fri, 21 Oct 2011 11:18:34 +0200
Subject: open_issues/glibc/debian: Update with recent findings.

See thread starting at id:"87k482r8rr.fsf@kepler.schwinge.homeip.net".
---
 open_issues/glibc/debian.mdwn | 26 ++++++++++++++++++++++----
 1 file changed, 22 insertions(+), 4 deletions(-)

(limited to 'open_issues')

diff --git a/open_issues/glibc/debian.mdwn b/open_issues/glibc/debian.mdwn
index ce6ba9d2..331632f3 100644
--- a/open_issues/glibc/debian.mdwn
+++ b/open_issues/glibc/debian.mdwn
@@ -37,10 +37,28 @@ fail.  (Same for `libc6-dev_extra_pkg_install` in `debian/sysdeps/i386.mk`, for
 example.)  Why is this special handling only done for `xen`, but not for
 `i686`?
 
+> Samuel: Historically because it's done that way in linux-i386. I don't know
+> the real reason.
+
 Do `export LC_ALL=C` before building, otherwise the testsuite/make error
 messages will be different from those stored in the
-`debian/testsuite-checking/expected-results-*` files.
+`debian/testsuite-checking/expected-results-*` files, resulting in a spurious
+build failure.
+
+Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`
+to build (or `build` instead of `build-arch` to build the arch-independent
+stuff, too).  Can interrupt with `C-c` during locale stuff or testsuite if only
+interested in the build tree.
+
+Run `fakeroot debian/rules binary DEB_BUILD_OPTIONS=parallel=2
+[EGLIBC_PASSES=...]` to build Debian packages or `binary-arch` for just the
+architecture-dependent ones.
+
+The latter two steps can also be combined as `dpkg-buildpackage -R'debian/rules
+EGLIBC_PASSES=libc' -nc -b -uc`.  `-nc` will prevent the *clean step* which
+would first try to un-patch, which may conflict if you have done any edits
+apter applying patches.
 
-Run `debian/rules build-arch DEB_BUILD_OPTIONS=parallel=2 [EGLIBC_PASSES=...]`.
-Can stop with `C-c` during locale stuff or testsuite if only interested in the
-build tree.
+If the Debian symbol versioning file is not up to date and the build of Debian
+packages fails due to this, putting `DPKG_GENSYMBOLS_CHECK_LEVEL=0` in the
+environment \`\`helps''; see `man dpkg-gensymbols`.
-- 
cgit v1.2.3


From f9e97cf3dac0fd1c99c0d3057da4eee0fa1feeed Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Sat, 22 Oct 2011 11:50:35 +0200
Subject: open_issues/binutils: Update.

---
 open_issues/binutils.mdwn             |  6 +++---
 open_issues/binutils/log_build.diff   | 14 +++++++-------
 open_issues/binutils/log_install.diff |  4 ++--
 open_issues/binutils/sum.diff         | 24 ++++++++++++------------
 open_issues/binutils/sum_hurd         | 13 +++++++------
 open_issues/binutils/sum_linux        | 13 +++++++------
 6 files changed, 38 insertions(+), 36 deletions(-)

(limited to 'open_issues')

diff --git a/open_issues/binutils.mdwn b/open_issues/binutils.mdwn
index b86ed607..246e819d 100644
--- a/open_issues/binutils.mdwn
+++ b/open_issues/binutils.mdwn
@@ -30,8 +30,8 @@ though, as explained below.
 
 # Configuration
 
-Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a
-(2011-10-11) sources|source_repositories/binutils]].
+Last reviewed up to the [[Git mirror's e605e0bc9fced128199177fff775851c7e50b4e5
+(2011-10-20) sources|source_repositories/binutils]].
 
   * Globally
 
@@ -108,7 +108,7 @@ Last reviewed up to the [[Git mirror's 066f3707e988b24f8f39d01f105662a814c0979a
 # Build
 
 Here's a log of a binutils build run; this is from our [[Git repository's
-11637a710adc7baea102d0ef5975b7a92b07aea1 (2011-10-11)
+6e78bdc1d64c55962d36ef29d15f06fb2415261b (2011-10-20)
 sources|source_repositories/binutils]], run on kepler.SCHWINGE and
 coulomb.SCHWINGE.
 
diff --git a/open_issues/binutils/log_build.diff b/open_issues/binutils/log_build.diff
index 79172cf6..79946f63 100644
--- a/open_issues/binutils/log_build.diff
+++ b/open_issues/binutils/log_build.diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2011-10-11 14:23:15.275568065 +0200
-+++ /dev/fd/62	2011-10-11 14:23:15.275568065 +0200
+--- /dev/fd/63	2011-10-22 11:44:16.461445903 +0200
++++ /dev/fd/62	2011-10-22 11:44:16.461445903 +0200
 @@ -276,12 +276,12 @@
  checking for sys/sysinfo.h... yes
  checking for machine/hal_sysinfo.h... no
@@ -214,7 +214,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
-@@ -2473,7 +2452,7 @@
+@@ -2475,7 +2454,7 @@
  checking for BSD- or MS-compatible name lister (nm)... nm
  checking the name lister (nm) interface... BSD nm
  checking whether ln -s works... yes
@@ -223,7 +223,7 @@
  checking whether the shell understands some XSI constructs... yes
  checking whether the shell understands "+="... no
  checking for ld option to reload object files... -r
-@@ -2494,7 +2473,7 @@
+@@ -2496,7 +2475,7 @@
  checking if gcc-4.6 supports -c -o file.o... (cached) yes
  checking whether the gcc-4.6 linker (ld) supports shared libraries... yes
  checking whether -lc should be explicitly linked in... no
@@ -232,7 +232,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether stripping libraries is possible... yes
  checking if libtool supports shared libraries... yes
-@@ -2510,7 +2489,7 @@
+@@ -2512,7 +2491,7 @@
  checking if g++-4.6 supports -c -o file.o... yes
  checking if g++-4.6 supports -c -o file.o... (cached) yes
  checking whether the g++-4.6 linker (ld) supports shared libraries... yes
@@ -241,7 +241,7 @@
  checking how to hardcode library paths into programs... immediate
  checking whether NLS is requested... yes
  checking for catalogs to be installed...  bg da es fi fr ga id ja sv tr vi zh_CN zh_TW
-@@ -2590,13 +2569,13 @@
+@@ -2592,13 +2571,13 @@
  /bin/dash ../../master/ld/../ylwrap ../../master/ld/ldgram.y y.tab.c ldgram.c y.tab.h ldgram.h y.output ldgram.output -- bison -y -d 
  updating ldgram.h
  (echo "/* This file is automatically generated.  DO NOT EDIT! */";\
@@ -257,7 +257,7 @@
  	 | sed -e 's/ e/ ld/g' -e 's/ ld/ /g' -e 's/[.]o//g'`; do \
  	    echo "  &ld_${f}_emulation, \\"; \
  	done;\
-@@ -2710,17 +2689,11 @@
+@@ -2712,17 +2691,11 @@
  gcc-4.6 -DHAVE_CONFIG_H -I. -I../../master/ld  -I. -I../../master/ld -I../bfd -I../../master/ld/../bfd -I../../master/ld/../include  -g -O2 -DENABLE_PLUGINS -DLOCALEDIR="\"[...]/hurd/master.build.install/share/locale\""  -W -Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT plugin.o -MD -MP -MF .deps/plugin.Tpo -c -o plugin.o ../../master/ld/plugin.c
  mv -f .deps/plugin.Tpo .deps/plugin.Po
  cp ../../master/ld/emultempl/astring.sed stringify.sed
diff --git a/open_issues/binutils/log_install.diff b/open_issues/binutils/log_install.diff
index 27dff188..100ebf5c 100644
--- a/open_issues/binutils/log_install.diff
+++ b/open_issues/binutils/log_install.diff
@@ -1,5 +1,5 @@
---- /dev/fd/63	2011-10-11 14:23:22.899444227 +0200
-+++ /dev/fd/62	2011-10-11 14:23:22.903444162 +0200
+--- /dev/fd/63	2011-10-22 11:44:48.780903894 +0200
++++ /dev/fd/62	2011-10-22 11:44:48.780903894 +0200
 @@ -68,7 +68,6 @@
  libtool: install: /usr/bin/install -c .libs/libbfd.a [...]/hurd/master.build.install/lib/libbfd.a
  libtool: install: chmod 644 [...]/hurd/master.build.install/lib/libbfd.a
diff --git a/open_issues/binutils/sum.diff b/open_issues/binutils/sum.diff
index a466b82c..0c612411 100644
--- a/open_issues/binutils/sum.diff
+++ b/open_issues/binutils/sum.diff
@@ -1,9 +1,9 @@
---- open_issues/binutils/sum_linux	2011-10-11 14:23:39.000000000 +0200
-+++ open_issues/binutils/sum_hurd	2011-10-11 14:23:33.000000000 +0200
+--- open_issues/binutils/sum_linux	2011-10-22 11:49:33.000000000 +0200
++++ open_issues/binutils/sum_hurd	2011-10-22 11:23:09.000000000 +0200
 @@ -1,5 +1,5 @@
--Test Run By thomas on Tue Oct 11 14:12:56 2011
+-Test Run By thomas on Sat Oct 22 11:43:32 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:36:51 2011
++Test Run By thomas on Fri Oct 21 12:54:58 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== binutils tests ===
@@ -12,9 +12,9 @@
  
  # of expected passes		90
  # of unsupported tests		3
--Test Run By thomas on Tue Oct 11 14:13:19 2011
+-Test Run By thomas on Sat Oct 22 11:43:59 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:38:54 2011
++Test Run By thomas on Fri Oct 21 12:56:51 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== ld tests ===
@@ -60,20 +60,20 @@
  PASS: ELF DSO small bar (size)
  PASS: ELF DSO foo with small bar (size)
  PASS: ELF DSO big bar (size)
-@@ -939,13 +939,13 @@ Running [...]/hurd/master/ld/testsuite/l
+@@ -940,13 +940,13 @@ Running [...]/hurd/master/ld/testsuite/l
  
  		=== ld Summary ===
  
--# of expected passes		671
+-# of expected passes		672
 -# of expected failures		8
-+# of expected passes		661
++# of expected passes		662
 +# of expected failures		18
  # of untested testcases		6
- [...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+ [...]/hurd/master.build/ld/ld-new 2.22.51.20111021
  
--Test Run By thomas on Tue Oct 11 14:13:02 2011
+-Test Run By thomas on Sat Oct 22 11:43:38 2011
 -Native configuration is i686-pc-linux-gnu
-+Test Run By thomas on Tue Oct 11 13:37:18 2011
++Test Run By thomas on Fri Oct 21 12:55:21 2011
 +Native configuration is i686-unknown-gnu0.3
  
  		=== gas tests ===
diff --git a/open_issues/binutils/sum_hurd b/open_issues/binutils/sum_hurd
index 7d12b17f..31f8f997 100644
--- a/open_issues/binutils/sum_hurd
+++ b/open_issues/binutils/sum_hurd
@@ -1,4 +1,4 @@
-Test Run By thomas on Tue Oct 11 13:36:51 2011
+Test Run By thomas on Fri Oct 21 12:54:58 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== binutils tests ===
@@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		90
 # of unsupported tests		3
-Test Run By thomas on Tue Oct 11 13:38:54 2011
+Test Run By thomas on Fri Oct 21 12:56:51 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== ld tests ===
@@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u
 PASS: --gc-sections -r without -e
 PASS: --gc-sections with note section
 PASS: --gc-sections with __start_
+PASS: --gc-sections with __gxx_personality
 PASS: --gc-sections with shared library
 Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ...
@@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		661
+# of expected passes		662
 # of expected failures		18
 # of untested testcases		6
-[...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+[...]/hurd/master.build/ld/ld-new 2.22.51.20111021
 
-Test Run By thomas on Tue Oct 11 13:37:18 2011
+Test Run By thomas on Fri Oct 21 12:55:21 2011
 Native configuration is i686-unknown-gnu0.3
 
 		=== gas tests ===
@@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 		=== gas Summary ===
 
 # of expected passes		346
-../as-new 2.22.51.20111011
+../as-new 2.22.51.20111021
 
diff --git a/open_issues/binutils/sum_linux b/open_issues/binutils/sum_linux
index f765b983..09c11722 100644
--- a/open_issues/binutils/sum_linux
+++ b/open_issues/binutils/sum_linux
@@ -1,4 +1,4 @@
-Test Run By thomas on Tue Oct 11 14:12:56 2011
+Test Run By thomas on Sat Oct 22 11:43:32 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== binutils tests ===
@@ -122,7 +122,7 @@ Running [...]/hurd/master/binutils/testsuite/binutils-all/x86-64/x86-64.exp ...
 
 # of expected passes		90
 # of unsupported tests		3
-Test Run By thomas on Tue Oct 11 14:13:19 2011
+Test Run By thomas on Sat Oct 22 11:43:59 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== ld tests ===
@@ -625,6 +625,7 @@ PASS: Check --gc-section/-r/-u
 PASS: --gc-sections -r without -e
 PASS: --gc-sections with note section
 PASS: --gc-sections with __start_
+PASS: --gc-sections with __gxx_personality
 PASS: --gc-sections with shared library
 Running [...]/hurd/master/ld/testsuite/ld-h8300/h8300.exp ...
 Running [...]/hurd/master/ld/testsuite/ld-i386/i386.exp ...
@@ -939,12 +940,12 @@ Running [...]/hurd/master/ld/testsuite/ld-xtensa/xtensa.exp ...
 
 		=== ld Summary ===
 
-# of expected passes		671
+# of expected passes		672
 # of expected failures		8
 # of untested testcases		6
-[...]/hurd/master.build/ld/ld-new 2.22.51.20111011
+[...]/hurd/master.build/ld/ld-new 2.22.51.20111021
 
-Test Run By thomas on Tue Oct 11 14:13:02 2011
+Test Run By thomas on Sat Oct 22 11:43:38 2011
 Native configuration is i686-pc-linux-gnu
 
 		=== gas tests ===
@@ -1416,5 +1417,5 @@ Running [...]/hurd/master/gas/testsuite/gas/z8k/z8k.exp ...
 		=== gas Summary ===
 
 # of expected passes		346
-../as-new 2.22.51.20111011
+../as-new 2.22.51.20111021
 
-- 
cgit v1.2.3


From be49aa7ddec52e121d562e14d4d93fd301b05fbb Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <tschwinge@gnu.org>
Date: Fri, 4 Nov 2011 19:19:35 +0100
Subject: IRC.

---
 glibc.mdwn                                         |   2 +
 glibc/ioctl.mdwn                                   |  52 +++++
 hurd.mdwn                                          |   1 +
 hurd/libdiskfs.mdwn                                |  42 ++++
 hurd/libstore/examples/ramdisk/discussion.mdwn     |  72 ++++++
 hurd/running/virtualbox.mdwn                       |   5 +
 hurd/translator/tmpfs/notes_various.mdwn           |   8 +
 open_issues/64-bit_port.mdwn                       |  36 +++
 open_issues/anatomy_of_a_hurd_system.mdwn          |  14 +-
 .../benefits_of_a_native_hurd_implementation.mdwn  |   2 +-
 open_issues/bsd_compatibility.mdwn                 |  34 +++
 open_issues/dde.mdwn                               |  25 ++-
 open_issues/dde/137784                             |  43 ++++
 open_issues/dev_zero_size.mdwn                     |  21 ++
 open_issues/device_drivers_and_io_systems.mdwn     |   4 +-
 open_issues/fifo_O_RDWR.mdwn                       |  25 +++
 open_issues/glibc.mdwn                             |   2 +
 open_issues/glibc/t/tls-threadvar.mdwn             |  24 ++
 open_issues/gnumach_memory_management.mdwn         |  33 +++
 open_issues/gnumach_memory_management_2.mdwn       | 246 +++++++++++++++++++++
 .../gnumach_memory_management_physical_memory.mdwn |  46 ++++
 open_issues/issue_tracking.mdwn                    |  78 +++++++
 open_issues/libpthread_assertion_thread_prevp.mdwn |  52 +++++
 .../libpthread_pthread_key_create_reuse.mdwn       |  37 +++-
 open_issues/libpthread_set_stack_size.mdwn         |  25 +++
 open_issues/mission_statement.mdwn                 |  39 ++++
 .../performance/io_system/binutils_ld_64ksec.mdwn  |   4 +
 open_issues/pfinet_vs_system_time_changes.mdwn     |  20 +-
 open_issues/screen_dead_session.mdwn               |  30 ++-
 open_issues/user-space_device_drivers.mdwn         |   4 +-
 open_issues/xen_lseek.mdwn                         |  35 +++
 source_repositories/discussion.mdwn                | 193 ++++++++++++++++
 32 files changed, 1239 insertions(+), 15 deletions(-)
 create mode 100644 glibc/ioctl.mdwn
 create mode 100644 hurd/libdiskfs.mdwn
 create mode 100644 hurd/libstore/examples/ramdisk/discussion.mdwn
 create mode 100644 open_issues/64-bit_port.mdwn
 create mode 100644 open_issues/bsd_compatibility.mdwn
 create mode 100644 open_issues/dde/137784
 create mode 100644 open_issues/dev_zero_size.mdwn
 create mode 100644 open_issues/fifo_O_RDWR.mdwn
 create mode 100644 open_issues/glibc/t/tls-threadvar.mdwn
 create mode 100644 open_issues/gnumach_memory_management_2.mdwn
 create mode 100644 open_issues/gnumach_memory_management_physical_memory.mdwn
 create mode 100644 open_issues/libpthread_assertion_thread_prevp.mdwn
 create mode 100644 open_issues/libpthread_set_stack_size.mdwn
 create mode 100644 open_issues/mission_statement.mdwn
 create mode 100644 open_issues/xen_lseek.mdwn
 create mode 100644 source_repositories/discussion.mdwn

(limited to 'open_issues')

diff --git a/glibc.mdwn b/glibc.mdwn
index 8eaff6ad..78d44df0 100644
--- a/glibc.mdwn
+++ b/glibc.mdwn
@@ -58,6 +58,8 @@ fact simply forwarded to/implemented as [[system_call]]s.
 
   * [[signal]]
 
+  * [[ioctl]]
+
 
 ## Individual functions
 
diff --git a/glibc/ioctl.mdwn b/glibc/ioctl.mdwn
new file mode 100644
index 00000000..e1a86f32
--- /dev/null
+++ b/glibc/ioctl.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 2011 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, 2011-10-31:
+
+    <pinotree> is there some example of translator replying to custom ioctl's?
+    <pinotree> let's say you define some ioctl (those which can be represented)
+      using the _IOW etc macros; how would a translator (or something else)
+      "register" and reply to them?
+    <youpi> it's not an easy thing
+    <youpi> see hurd/hurd/tioctl.defs for instance
+    <youpi> that's where the 't' ioctls end up
+    <youpi> ('t' being the group in the _IOW macro)
+    <braunr> it's not that hard either
+    <pinotree> youpi: so you "roll" the ioctl to an ipc call with proper
+      parameters?
+    <braunr> yes
+    <pinotree> ah ok, i thought there was some way to hook new ioctl's, and
+      have libc send the whole stuff at once
+    <braunr> and the proper number (with a clear name)
+    <braunr> hm
+    <braunr> for many ioctls, you don't have to change libc
+    <youpi> yes, there's a script which produces the .defs from _IOW calls,
+      iirc
+    <youpi> or something like this
+    <youpi> there's also a hook thing in glibc, but for "sane" ioctls, that's
+      not needed
+    <youpi> (_hurd_lookup_ioctl_handler called by ioctl())
+    <youpi> yes, see the rules in hurd/hurd/Makefile
+    <youpi> "The following rules assist in creating an `Xioctl.defs' file  to
+      define RPCs that are sent primarily by ioctl commands."
+    <antrik> well, you can have perfectly sane ioctl()s that still can't be
+      expressed within the constraints of the IO* macros... but admittedly
+      that's rather uncommon
+    <antrik> (unless you consider passing of structs generally insane...)
+    <youpi> I didn't want to spend time on finding an appropriate adjective
+      instaed of "sane"
+    <youpi> while I knew he would understand what I meant (and you did)
+    <youpi> (though  maybe not actually)
+    <youpi> by "sane", I mean, which use _IOW properly
+    <youpi> i.e. with a group, proper numbers, etc.
+    <youpi> (the imposed contraints on the parameters is obviously a flaw in
+      the hurdish ioctl design, and not insanity from structures)
diff --git a/hurd.mdwn b/hurd.mdwn
index 7bf98388..255cd3d7 100644
--- a/hurd.mdwn
+++ b/hurd.mdwn
@@ -92,6 +92,7 @@ in the *unstable* branch of the Debian archive.
   * [[libchannel]]
   * [[libtrivfs]]
   * [[libnetfs]] -- short introductory material
+  * [[libdiskfs]]
   * [[libihash]]
   * [[libpthread]]
 * [[IO_Path]]
diff --git a/hurd/libdiskfs.mdwn b/hurd/libdiskfs.mdwn
new file mode 100644
index 00000000..dd499785
--- /dev/null
+++ b/hurd/libdiskfs.mdwn
@@ -0,0 +1,42 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+
+# Paging
+
+In the course of Maksym's [[translator/tmpfs]] work:
+
+IRC, freenode, #hurd, 2011-10-24:
+
+    <mcsim> I've compared the way pagers are handled in ext2fs and found out
+      that for every file new pager is created when occurs reading or writing
+      to this file. Is it necessary? And can one pager handle several memory
+      objects?
+    <antrik> mcsim: yes, this in necessary. one pager port corresponds to one
+      memory object
+    <antrik> mcsim: note that a pager, from the kernel's point of view, is
+      essentially just the port used to communicated with the process
+      responsible for paging the object. how your process manages multiple
+      pager ports is up to you
+    <mcsim> so, how can I attach those pager_* functions, which are declared
+      now in pager-stubs.c to new pager?
+    <mcsim> or is it done automatically with all pagers, which I create, If
+      only I'm not using default one?
+    <antrik> I'm not sure how libpager works; but I suspect it's based on
+      libports. you probably need a port class for the pager ports, and add the
+      port for each new pager your create to that class
+    <antrik> (of course you also need to add it to some port bucket. if you use
+      a single dispatcher for everything, this would be the default bucket; if
+      you want a separate thread for pager handling, you'd have to create an
+      extra bucket for the pagers)
+
+This is the `diskfs_get_filemap` function that a `libdiskfs` client has to
+provide; used in `libdiskfs/rdwr-internal.c:_diskfs_rdwr_internal`, which in
+turn is used by the [[interface/io_read]]/[[interface/io_write]] RPCs.
diff --git a/hurd/libstore/examples/ramdisk/discussion.mdwn b/hurd/libstore/examples/ramdisk/discussion.mdwn
new file mode 100644
index 00000000..d73bf903
--- /dev/null
+++ b/hurd/libstore/examples/ramdisk/discussion.mdwn
@@ -0,0 +1,72 @@
+[[!meta copyright="Copyright © 2011 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_hurd]]
+
+
+# IRC, freenode, #hurd, 2011-10-15
+
+    <antrik> youpi: I'm not at all talking about ordinary tmpfs. I'm talking
+      about the proposed variant using a separate backing store
+    <antrik> youpi: and as you might remember, I once came up with a crazy
+      passive translator command line (based on another crazy passive
+      translator command line from tschwinge) that can automatically do the
+      mkfs
+    <antrik> so there is really very little benefit in using something else
+      than ext2fs when not paging to the swap partition
+    <antrik> real tmpfs IMHO is mostly useful precisely because it uses the
+      ordinary swap, and doesn't have an explicit size limit...
+    <youpi> well, it is still quite a waste to bounce data betwen page cache
+      and memory storage
+    <youpi> or is ext2fs able to map the store data directly?
+    <youpi> then there's only the medata bounce which is spurious
+    <youpi> and still, even a one-liner settrans doesn't fit with the "is just
+      an fs alternative for the existing tmpfs-mounting scripts"
+    <antrik> youpi: well, if the invocation is the major concern, it would be
+      trivial to write a tiny wrapper binary or script that acts like a
+      "normal" FS...
+    <youpi> antrik: could you write it then?
+    <antrik> you mean a shell script that uses ext2fs on a memory store to act
+      like a "proper" tmpfs?
+    <youpi> I mean whatever that permits to just run mount none /tmp -t tmpfs
+    <youpi> and just works already nowadays
+    <youpi> which we could e.g. ship instead of our currently-completely bugged
+      tmpfs
+    <antrik> I suspect the mount script just looks for /hurd/tmpfs in this
+      case? if so, that should indeed be pretty trivial. let's see if I can dig
+      up my crazy command line -- turning that into a "proper" script should be
+      quite easy I hope...
+    <antrik> hm... I digged up
+      http://lists.gnu.org/archive/html/bug-hurd/2007-04/msg00013.html ; but I
+      wonder how much of it is really necessary for a generic pseudo-tmpfs...
+    <antrik> the major complication seems to be the chmod, which I guess we
+      don't need for most use cases...
+    <youpi> I actually don't see why it's inlined there
+    <youpi> doesn't the caller do it if it needs it?
+    <youpi> ah, well, here there is no caller, it's just a passive entry
+    <antrik> is it a problem that this solution needs an extra node for the
+      store?
+    <youpi> yes
+    <youpi> because you need to say where it resides
+    <youpi> and there's no safe place
+    <youpi> since such safe place would typically be a mounted tmpfs
+    <antrik> I feared that much...
+    <antrik> I suspect we could work around this by not attaching the store to
+      any node; but this a) doesn't work in a shell script, and b) is much more
+      involved...
+    <antrik> hm... can we assume /dev/fd to be present? I have a vague crazy
+      idea...
+    <youpi> yes
+    <antrik> I consider hacking settrans so it grows an option which allows
+      passing the port to the translator as an FD, instead of attaching it to
+      any node... this way, we could work with anonymous translators in shell
+      scripts :-)
+    <antrik> (of course that's not less work than just doing the wrapper in
+      C... but it could be useful in other cases)
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index d9be09f2..f57fcbc3 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -39,3 +39,8 @@ To convert the image you need the VirtualBox package properly installed with a V
 
 If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better
 performance.
+
+IRC, freenode, #hurd, 2011-10-31:
+
+    <youpi> I don't know what virtualbox does with hardware emulation, but
+      gnumach is awfully slow to probe things there
diff --git a/hurd/translator/tmpfs/notes_various.mdwn b/hurd/translator/tmpfs/notes_various.mdwn
index d16210ca..d1c5cf62 100644
--- a/hurd/translator/tmpfs/notes_various.mdwn
+++ b/hurd/translator/tmpfs/notes_various.mdwn
@@ -212,3 +212,11 @@ License|/fdl]]."]]"""]]
     <antrik> seems something more broke in the meantime :-(
     <antrik> ah, right... but I the main problem was some other change
     <antrik> (or maybe it never really worked, not sure anymore)
+
+---
+
+IRC, freenode, #hurd, 2011-10-11:
+
+    <mcsim> There is no patch for "tmpfs crashes on filling an empty file". For
+      second bug there is Zheng Da's patch, but it wasn't applied (at least I
+      didn't found).
diff --git a/open_issues/64-bit_port.mdwn b/open_issues/64-bit_port.mdwn
new file mode 100644
index 00000000..797d540f
--- /dev/null
+++ b/open_issues/64-bit_port.mdwn
@@ -0,0 +1,36 @@
+[[!meta copyright="Copyright © 2011 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 open_issue_mig]]
+
+IRC, freenode, #hurd, 2011-10-16:
+
+    <youpi> it'd be really good to have a 64bit kernel, no need to care about
+      addressing space :)
+    <braunr> yes a 64 bits kernel would be nice
+    <braunr> i guess it wouldn't be too hard to have a special mach kernel for
+      64 bits processors, but 32 bits userland only
+    <youpi> well, it means tinkering with mig
+    <braunr> like old sparc systems :p
+    <youpi> to build the 32bit interface, not the 64bit one
+    <braunr> ah yes
+    <braunr> hm
+    <braunr> i'm not sure
+    <braunr> mig would assume a 32 bits kernel, like now
+    <youpi> and you'll have all kinds of discrepancies in vm_size_t & such
+    <braunr> yes
+    <braunr> the 64 bits type should be completely internal
+    <braunr> types*
+    <braunr> but it would be far less work than changing all the userspace bits
+      for 64 bit (ofc we'll do that some day but in the meanwhile ..)
+    <youpi> yes
+    <youpi> and it'd boost userland addrespace to 4GiB
+    <braunr> yes
+    <youpi> leaving time for a 64bit userland :)
diff --git a/open_issues/anatomy_of_a_hurd_system.mdwn b/open_issues/anatomy_of_a_hurd_system.mdwn
index 64af3d00..46526641 100644
--- a/open_issues/anatomy_of_a_hurd_system.mdwn
+++ b/open_issues/anatomy_of_a_hurd_system.mdwn
@@ -13,7 +13,7 @@ License|/fdl]]."]]"""]]
 A bunch of this should also be covered in other (introductionary) material,
 like Bushnell's Hurd paper.  All this should be unfied and streamlined.
 
-IRC, freenode, #hurd, 2011-03-08
+IRC, freenode, #hurd, 2011-03-08:
 
     <foocraft> I've a question on what are the "units" in the hurd project, if
       you were to divide them into units if they aren't, and what are the
@@ -40,7 +40,7 @@ IRC, freenode, #hurd, 2011-03-08
 
 ---
 
-IRC, freenode, #hurd, 2011-03-12
+IRC, freenode, #hurd, 2011-03-12:
 
     <dEhiN> when mach first starts up, does it have some basic i/o or fs
       functionality built into it to start up the initial hurd translators?
@@ -86,3 +86,13 @@ RPC stubs.
 ---
 
 More stuff like [[hurd/IO_path]].
+
+--
+
+IRC, freenode, #hurd, 2011-10-18:
+
+    <frhodes> what happens @ boot. and which translators are started in what
+      order?
+    <antrik> short version: grub loads mach, ext2, and ld.so/exec; mach starts
+      ext2; ext2 starts exec; ext2 execs a few other servers; ext2 execs
+      init. from there on, it's just standard UNIX stuff
diff --git a/open_issues/benefits_of_a_native_hurd_implementation.mdwn b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
index d796bf6b..afdcfb73 100644
--- a/open_issues/benefits_of_a_native_hurd_implementation.mdwn
+++ b/open_issues/benefits_of_a_native_hurd_implementation.mdwn
@@ -27,7 +27,7 @@ IRC, #hurd, August / September 2010
       runs Linux in user space (just flip the two) for the drivers
     <marcusb> ArneBab: that is what the L4 people did with the DDE
 
-([[DDE]])
+[[/DDE]].
 
     <marcusb> ArneBab: so, with these different cuts, there are different
       opportunities. on the one end, you can run Linux as normal and get some
diff --git a/open_issues/bsd_compatibility.mdwn b/open_issues/bsd_compatibility.mdwn
new file mode 100644
index 00000000..5c916908
--- /dev/null
+++ b/open_issues/bsd_compatibility.mdwn
@@ -0,0 +1,34 @@
+[[!meta copyright="Copyright © 2011 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, 2011-10-12:
+
+    <pinotree> hm, why our sys/param.h #define's BSD?
+    <braunr> pinotree: because we're evil
+    <pinotree> is that correct?
+    <pinotree> (the define, not the evilness)
+    <braunr> pinotree: i think it's because the Hurd is closer to the BSD
+      interfaces, probably because of Mach (which is itself derived from
+      BSD4.2)
+    <pinotree> braunr: but mach being bsd-ish won't make the userland (glibc)
+      interfaces bsd-ish, will it?
+    <braunr> pinotree: no
+    <pinotree> braunr: so...? :)
+    <braunr> pinotree: i guesse there are bsdisms in the glibc hurd specific
+      code, possibly because of mach
+    <braunr> or they used to be bsdisms, before being standardized
+    <braunr> e.g. mmap
+    <pinotree> braunr: hrmm...
+    <antrik> braunr: the BSDisms are there on purpose... Hurd was originally
+      even meant to be binary-compatible with BSD
+    <antrik> nothing to do with Mach really
+    <braunr> antrik: ok
diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index ef319a5c..9e2ec742 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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,4 +8,25 @@ 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 redir=/dde]]
+[[General Information|/dde]].
+
+
+# IRC, freenode, #hurd, 2011-10-18
+
+[[!tag open_issue_hurd]]
+
+    [DDE crash, or similar]
+    <youpi> it's fake_local_irq_disable_flags(), then raw_local_irq_disable(),
+      then raw_local_irq_restore(), which *does not* release the cli_lock
+    <youpi> the "prove it" comment is (as I expected) completely wrong
+    <youpi> npnth: http://paste.debian.net/137784/
+
+[[137784]]
+
+    <youpi> could you try this patch ?
+    <youpi> (I've not even tried to build it)
+    <npnth> youpi: speaking of which, it still seems to hang :/  I'll 1) double
+      check it applied correctly and 2) get a gdb output if it did
+    <youpi> npnth: could you add printing the value of unlock_refcnt?
+    <youpi> so we can check what's happening
+    <npnth> unlock_refcnt is at 0, interesting
diff --git a/open_issues/dde/137784 b/open_issues/dde/137784
new file mode 100644
index 00000000..1529465b
--- /dev/null
+++ b/open_issues/dde/137784
@@ -0,0 +1,43 @@
+diff --git a/libdde_linux26/lib/src/arch/l4/cli_sti.c b/libdde_linux26/lib/src/arch/l4/cli_sti.c
+index 051f259..6a8c460 100644
+--- a/libdde_linux26/lib/src/arch/l4/cli_sti.c
++++ b/libdde_linux26/lib/src/arch/l4/cli_sti.c
+@@ -4,6 +4,8 @@
+ 
+ /* IRQ lock reference counter */
+ static atomic_t      _refcnt   = ATOMIC_INIT(0);
++/* Refcnt value at which unlocking the cli_lock (it's not always 0) */
++static int unlock_refcnt;
+ static ddekit_lock_t cli_lock;
+ 
+ /* Check whether IRQs are currently disabled.
+@@ -57,9 +59,6 @@ void fake_local_irq_restore(unsigned long flags)
+ /* Store the current flags state.
+  *
+  * This is done by returning the current refcnt.
+- *
+- * XXX: Up to now, flags was always 0 at this point and
+- *      I assume that this is always the case. Prove?
+  */
+ unsigned long __raw_local_save_flags(void)
+ {
+@@ -82,7 +81,7 @@ void raw_local_irq_restore(unsigned long flags)
+ {
+ 	Assert(cli_lock != NULL);
+ 	atomic_set(&_refcnt, flags);
+-	if (flags == 0)
++	if (flags == unlock_refcnt)
+ 		ddekit_lock_unlock(&cli_lock);
+ }
+ 
+@@ -95,7 +94,9 @@ void raw_local_irq_disable(void)
+ 	if (cli_lock == NULL)
+ 		ddekit_lock_init_unlocked(&cli_lock);
+ 
+-	nested_lock(cli_lock);
++	if (nested_lock(cli_lock))
++		/* Tell the corresponding restorer to release cli_lock */
++		unlock_refcnt = atomic_read(&_refcnt);
+ 	atomic_inc(&_refcnt);
+ }
+ 
diff --git a/open_issues/dev_zero_size.mdwn b/open_issues/dev_zero_size.mdwn
new file mode 100644
index 00000000..20c5147e
--- /dev/null
+++ b/open_issues/dev_zero_size.mdwn
@@ -0,0 +1,21 @@
+[[!meta copyright="Copyright © 2011 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_hurd]]
+
+IRC, freenode, #hurd, 2011-10-18:
+
+    <pinotree> i guess it is not normal for /dev/zero have a size of
+      (size_t)-1, no?
+    <pinotree> (it isn't (size_t)-1, but (long long)-1)
+
+2011-10-19:
+
+    <pinotree> see the size you get with `stat /dev/zero`
diff --git a/open_issues/device_drivers_and_io_systems.mdwn b/open_issues/device_drivers_and_io_systems.mdwn
index ce50d93e..5bda0213 100644
--- a/open_issues/device_drivers_and_io_systems.mdwn
+++ b/open_issues/device_drivers_and_io_systems.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2009, 2011 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
@@ -68,7 +68,7 @@ Also see [[user-space device drivers]].
 
 # External Projects
 
-  * [[DDE]]
+  * [[/DDE]]
 
   * [Building Linux Device Drivers on
     FreeBSD](http://info.iet.unipi.it/~luigi/FreeBSD/linux_bsd_kld.html)
diff --git a/open_issues/fifo_O_RDWR.mdwn b/open_issues/fifo_O_RDWR.mdwn
new file mode 100644
index 00000000..730e5c6f
--- /dev/null
+++ b/open_issues/fifo_O_RDWR.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2011 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="fifo O_RDWR"]]
+
+[[!tag open_issue_hurd]]
+
+[[!debbug 646016]]
+
+IRC, OFTC, #debian-hurd, 2011-10-19:
+
+    <tschwinge> pinotree: Nice!  And that open(FIFO, O_RDWR) hanging issue may
+      warrant investigation on the Hurd side, too -- if the other systems
+      behave differently, we should probably have convincing reasons for our
+      behavior.
+    <pinotree> i gue somebody working on hurd never cared about that case - i
+      guess it falls back to one of O_RDONLY or O_WRONLY
+    <pinotree> *guess
diff --git a/open_issues/glibc.mdwn b/open_issues/glibc.mdwn
index e48dde9c..d3f88673 100644
--- a/open_issues/glibc.mdwn
+++ b/open_issues/glibc.mdwn
@@ -59,6 +59,8 @@ Last reviewed up to the [[Git mirror's 187da0aedcd9d0a2fb34477bef41549681ba1273
 
       * `TLS_INIT_TP_EXPENSIVE` is unused; Hurd def. can be removed.
 
+  * [[t/tls-threadvar]]
+
   * t/verify.h
 
     People didn't like this too much.
diff --git a/open_issues/glibc/t/tls-threadvar.mdwn b/open_issues/glibc/t/tls-threadvar.mdwn
new file mode 100644
index 00000000..f6a81590
--- /dev/null
+++ b/open_issues/glibc/t/tls-threadvar.mdwn
@@ -0,0 +1,24 @@
+[[!meta copyright="Copyright © 2011 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 open_issue_libpthread]]
+
+IRC, freenode, #hurd, 2011-10-23:
+
+    <tschwinge> youpi: If we want to replace threadvars with TLS, there is one
+      problem: the threadvars interface is publically exported:
+      /usr/include/hurd/threadvar.h.
+    <tschwinge> youpi: But I am somewhat inclined to say that the only user of
+      this is libthreads/libpthread.  Do you think differently?
+    <youpi> tschwinge: that's very probable
+    <youpi> so I think we can just drop it
+    <youpi> (people should use TLS anyway)
+
+[[libpthread_set_stack_size]].
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index fb3d6895..9a4418c1 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -1777,3 +1777,36 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task.
     <braunr> an idea for when there's time
     <braunr> eh
     <antrik> hehe :-)
+
+
+# IRC, freenode, #hurd, 2011-10-13
+
+    <braunr> mcsim: what's the current state of your gnumach branch ?
+    <mcsim> I've merged it with master in September
+    <braunr> yes i've seen that, but does it build and run fine ?
+    <mcsim> I've tested it on gnumach from debian repository, but for building
+      I had to make additional change in device/ramdisk.c, as I mentioned.
+    <braunr> mcsim: why ?
+    <mcsim> And it runs fine for me.
+    <braunr> mcsim: why did you need to make other changes ?
+    <mcsim> because there is a patch which comes with from-debian-repository
+      kernel and it addes some code, where I have to make changes. Earlier
+      kernel_map was a pointer to structure, but I change that and now
+      kernel_map is structure. So handling to it should be by taking the
+      address (&kernel_map)
+    <braunr> why did you do that ?
+    <braunr> or put it another way: what made you do that type change on
+      kernel_map ?
+    <mcsim> Earlier memory for kernel_map was allocating with zalloc. But now
+      salloc can't allocate memory before it's initialisation
+    <braunr> that's not a good reason
+    <braunr> a simple workaround for your problem is this :
+    <braunr> static struct vm_map kernel_map_store;
+    <braunr> vm_map_t kernel_map = &kernel_map_store;
+    <mcsim> braunr: Ok. I'll correct this.
+
+
+# IRC, freenode, #hurd, 2011-11-01
+
+    <braunr> etenil: but mcsim's work is, for one, useful because the allocator
+      code is much clearer, adds some debugging support, and is smp-ready
diff --git a/open_issues/gnumach_memory_management_2.mdwn b/open_issues/gnumach_memory_management_2.mdwn
new file mode 100644
index 00000000..64aae2a4
--- /dev/null
+++ b/open_issues/gnumach_memory_management_2.mdwn
@@ -0,0 +1,246 @@
+[[!meta copyright="Copyright © 2011 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, 2011-10-16:
+
+    <youpi> braunr: I realize that kmem_alloc_wired maps the allocated pages in
+      the kernel map
+    <youpi> it's a bit of a waste when my allocation is exactly a page size
+    <youpi> is there a proper page allocation which would simply return its
+      physical address?
+    <youpi> pages returned by vm_page_grab  may get swapped out, right?
+    <youpi> so could it be a matter of calling vm_page_alloc then vm_page_wire
+      (with lock_queues held) ?
+    <youpi> s/alloc/grab/
+    <braunr> vm_page_grab() is only used at boot iirc
+    <braunr> youpi: mapping allocated memory in the kernel map is normal, even
+      if it's only a page
+    <braunr> the allocated area usually gets merged with an existing
+      vm_map_entry
+    <braunr> youpi: also, i'm not sure about what you're trying to do here, so
+      my answers may be out of scope :p
+    <youpi> saving addressing space
+    <youpi> with that scheme we're using twice as much addressing space for
+      kernel buffers
+    <braunr> kernel or user task ?
+    <youpi> kernl
+    <braunr> hm are there so many wired areas ?
+    <youpi> several MiBs, yes
+    <youpi> there are also the zalloc areas
+    <braunr> that's pretty normal
+    <youpi> which I've recently incrased
+    <braunr> hm forget what i've just said about vm_page_grab()
+    <braunr> youpi: is there a particular problem caused by kernel memory
+      exhaustion ?
+    <youpi> I currently can't pass the dh_strip stage of iceweasel due to this
+    <youpi> it can not allocate a stack 
+    <braunr> a kernel thread stack ?
+    <youpi> yes
+    <braunr> that's surprising
+    <youpi> it'd be good to have a kernel memory profile
+    <braunr> vminfo is able to return the kernel map
+    <youpi> well, it's not suprising if the kernel map is full
+    <youpi> but it doesn't tell what allocates which p ieces
+    <braunr> that's what i mean, it's surprising to have a full kernel map
+    <youpi> (that's what profiling is about)
+    <braunr> right
+    <youpi> well, it's not really surprising, considering that the krenel map
+      size is arbitrarily chosen
+    <braunr> youpi: 2 GiB is really high enough
+    <youpi> it's not 2GiB, precisely
+    <youpi> there is much of the 2GiB addr space which is spent on physical
+      memory mapping
+    <youpi> then there is the virtual mapping
+    <braunr> are you sure we're talking about the kernel map, or e.g. the kmem
+      map
+    <youpi> which is currently only 192MiB
+    <youpi> the kmem_map part of kernel_map
+    <braunr> ok, the kmem_map submap then
+    <braunr> netbsd has used 128 MiB for yeas with almost no issue
+    <braunr> mach uses more kernel objects so it's reasonable to have a bigger
+      map
+    <braunr> but that big ..
+    <youpi> I've made the zalloc areas quite big
+    <youpi> err, not only zalloc area
+    <braunr> kernel stacks are allocated directly from the kernel map
+    <youpi> kalloc to 64MiB, zalloc to 64MiB
+    <youpi> ipc map size to 8MiB
+    <braunr> youpi: it could be the lack of kernel map entries
+    <youpi> and the device io map to 16MiB
+    <braunr> do you have the exact error message ?
+    <youpi> no more room for vm_map_find_entry in 71403294
+    <youpi> no more rooom for kmem_alloc_aligned in 71403294
+    <braunr> ah, aligned
+    <youpi> for a stack
+    <youpi> which is 4 pages only
+    <braunr> memory returned by kmem functions always return pages
+    <braunr> hum
+    <braunr> kmem functions always return memory in page units
+    <youpi> and my xen driver is allocating 1MiB memory for the network buffer
+    <braunr> 4 pages for kernel stacks ?
+    <youpi> through kmem_alloc_wire
+    <braunr> that seems a lot
+    <youpi> that's needed for xen page updates
+    <youpi> without having to split the update in several parts
+    <braunr> ok
+    <braunr> but are there any alignment requirements ?
+    <youpi> I guess mach  uses the alignment trick to find "self"
+    <youpi> anyway, an alignment on 4pages shouldn't be a problem
+    <braunr> i think kmem_alloc_aligned() is the generic function used both for
+      requests with and without alignment constraints
+    <youpi> so I was thinking about at least moving my xen net driver to
+      vm_grab_page instead of kmem_alloc
+    <youpi> and along this, maybe others
+    <braunr> but you only get a vm_page, you can't access the memory it
+      describes
+    <youpi> non, a lloc_aligned always aligns
+    <youpi> why?
+    <braunr> because it's not mapped
+    <youpi> there's even vm_grab_page_physical_addr
+    <youpi> it is, in the physical memory map
+    <braunr> ah, you mean using the direct mapped area
+    <youpi> yes
+    <braunr> then yes
+    <braunr> i don't know that part much
+    <youpi> what I'm afraid of is the wiring
+    <braunr> why ?
+    <youpi> because I don't want to see my page swapped out :)
+    <youpi> or whatever might happen if I don't wire it
+    <braunr> oh i'm almost sure you won't
+    <youpi> why?
+    <youpi> why some people need to wire it, and I won't?
+    <braunr> because in most mach vm derived code i've seen, you have to
+      explicitely tell the vm your area is pageable
+    <youpi> ah,  mach does such thing indeed
+    <braunr> wiring can be annoying when you're passing kernel data to external
+      tasks
+    <braunr> you have to make sure the memory isn't wired once passed
+    <braunr> but that's rather a security/resource management problem
+    <youpi> in the net driver case, it's not passed to anything else
+    <youpi> I'm seeing 19MiB kmem_alloc_wired atm
+    <braunr> looks ok to me
+    <braunr> be aware that the vm_resident code was meant for single page
+      allocations
+    <youpi> what does this mean?
+    <braunr> there is no buddy algorithm or anything else decent enough wrt
+      performance
+    <braunr> vm_page_grab_contiguous_pages() can be quite slow
+    <youpi> err, ok, but what is the relation with the question at stake ?
+    <braunr> you need 4 pages of direct mapped memory for stacks
+    <braunr> those pages need to be physically contiguous if you want to avoid
+      the mapping
+    <braunr> allocating physically contiguous pages in mach is slow
+    <braunr> :)
+    <youpi> I didn't mean I wanted to avoid the mapping for stacks
+    <youpi> for anything more than a page, kmem mapping should be fine
+    <youpi> I'm concerned with code which allocates only page per page
+    <youpi> which thus really doesn't need any mapping
+    <braunr> i don't know the mach details but in derived implementations,
+      there is almost no overhead when allocating single pages
+    <braunr> except for the tlb programming
+    <youpi> well, there is: twice as much addressing space
+    <braunr> well
+    <braunr> netbsd doesn't directly map physical memory
+    <braunr> and for others, like freebsd
+    <braunr> the area is just one vm_map_entry
+    <braunr> and on modern mmus, 4 MiBs physical mappings are used in pmap
+    <youpi> again, I don't care about tlb & performance
+    <youpi> just about the addressing space
+    <braunr> hm
+    <braunr> you say "twice"
+    <youpi> which is short when you're trying to link crazy stuff like
+      iceweasel & co
+    <youpi> yes
+    <braunr> ok, the virtual space is doubled
+    <youpi> yes
+    <braunr> but the resources consume to describe them aren't
+    <braunr> even on mach
+    <youpi> since you have both the physical mapping and the kmem mapping
+    <youpi> I don't care much about the resources
+    <youpi> but about addressing space
+    <braunr> well there are a limited numbers of solutions
+    <youpi> the space it takes  and has to be taken from something else, that
+      is,  here physical memory available to Mach
+    <braunr> reduce the physical mapping
+    <braunr> increase the kmem mapping
+    <braunr> or reduce kernel memory consumption
+    <youpi> and instead of taking the space from physical  mapping, we can as
+      well avoid doubling the space consumption when it's trivial lto
+    <youpi> yes, the hird
+    <youpi> +t
+    <youpi> that's what I'm asking from the beginning :)
+    <braunr> 18:21 < youpi> I don't care much about the resources
+    <braunr> actually, you care :)
+    <youpi> yes and no
+    <braunr> i understand what you mean
+    <youpi> not in the sense "it takes a page_t to allocate a page"
+    <braunr> you want more virtual space, and aren't that much concerned about
+      the number of objects used
+    <youpi> yes
+    <braunr> then it makes sense
+    <braunr> but in this case, it could be a good idea to generalize it
+    <braunr> have our own kmalloc/vmalloc interfaces
+    <braunr> maybe a gsoc project :)
+    <youpi> err, don't we have them already?
+    <youpi> I mean, what exactly do you want to generalize?
+    <braunr> mach only ever had vmalloc
+    <youpi> we already have a hell lot of allocators :)
+    <youpi> and it's a pain to distribute the available space to them
+    <braunr> yes
+    <braunr> but what you basically want is to introduce something similar to
+      kmalloc for single pages
+    <youpi> or just patch the few cases that need it into just grabbing a page
+    <youpi> there are probably not so many
+    <braunr> ok
+    <braunr> i've just read vm_page_grab()
+    <braunr> it only removes a page from the free list
+    <braunr> other functions such as vm_page_alloc insert them afterwards
+    <braunr> if a page is in no list, it can't be paged out
+    <braunr> so i think it's probably safe to assume it's naturally wired
+    <braunr> you don't even need a call to vm_page_wire or a flag of some sort
+    <youpi> ok
+    <braunr> although considering the low amount of work done by
+      vm_page_wire(), you could, for clarity
+    <youpi> braunr: I was also wondering about the VM_PAGE_FREE_RESERVED & such
+      constants
+    <youpi> they're like 50 pages
+    <youpi> is this still reasonable  nowadays?
+    <braunr> that's a question i'm still asking myself quite often :)
+    <youpi> also, the BURST_{MAX,MIN} & such in vm_pageout.c are probably out
+      of date?
+    <braunr> i didn't study the pageout code much
+    <youpi> k
+    <braunr> but correct handling of low memory thresholds is a good point to
+      keep in mind
+    <braunr> youpi: i often wonder how linux can sometimes have so few free
+      pages left and still be able to work without any visible failure
+    <youpi> well, as long as you have enough pages to be able to make progress,
+      you're fine
+    <youpi> that' the point of the RESERVED pages in mach I guess
+    <braunr> youpi: yes but, obviously, hard values are *bad*
+    <braunr> linux must adjust it, depending on the number of processors, the
+      number of pdflush threads, probably other things i don't have in mind
+    <braunr> i don't know what should make us adjust that value in mach
+    <youpi> which value?
+    <braunr> the size of the reserved pool
+    <youpi> I don't think it's adjusted
+    <braunr> that's what i'm saying
+    <braunr> i guess there is an #ifndef line for arch specific definitions
+    <youpi> err, you just said linux must adjust it :
+    <youpi> ))
+    <youpi> there is none
+    <braunr> linux adjusts it dynamically
+    <braunr> well ok
+    <braunr> that's another way to say it
+    <braunr> we don't have code to get rid of this macro
+    <braunr> but i don't even know how we, as maintainers, are supposed to
+      guess it
diff --git a/open_issues/gnumach_memory_management_physical_memory.mdwn b/open_issues/gnumach_memory_management_physical_memory.mdwn
new file mode 100644
index 00000000..58fefe1f
--- /dev/null
+++ b/open_issues/gnumach_memory_management_physical_memory.mdwn
@@ -0,0 +1,46 @@
+[[!meta copyright="Copyright © 2011 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, 2011-10:
+
+    <braunr> antrik: about our physical memory limitations, i told you some
+      time ago that part of it was due to the linux drivers
+    <braunr> and i mentioned the paper concerning the integration of the linux
+      drivers written at the time
+    <braunr> it does indeed tell that mach, which used the common 3G->4G area
+      for the kernel space had to be adapted
+    <braunr> because linux used segmentation so that kernel addresses matched
+      physical addresses
+    <braunr> and it looks like some (many) drivers require that
+    <braunr> our current gnumach actually does this (which i found surprising
+      when i first found it)
+    <braunr> and i believe the easy solution to exceed this limitation is to
+      use a strategy similar to what linux still does on i386
+    <braunr> some highmem support
+    <braunr> we could alter the vm_resident module so that, by default, it
+      still looks for pages in the low 0-800 (or 0-1800 on debian patched
+      kernels) area
+    <braunr> but for everything else than the kernel, e.g. all user processes
+    <braunr> we could use a flag or a specialized function that would first
+      look in the highmem pool for available physical pages to map
+    <braunr> the only thing i'm not yet sure of is about user/kernel transfers
+    <braunr> if virtual addresses and copies are always cleanly done, then it's
+      ok
+    <braunr> and i really hope our linux drivers do so :)
+    <braunr> (i mean ,the glue code ofc)
+
+2011-10-23:
+
+    <youpi> braunr: I believe, like Linus, that highmem support is a nightmare
+    <antrik> braunr: uhm... the drivers want virtual addressses to match
+      physical ones? I guess that means switching address spaces before any
+      driver code is executed?...
diff --git a/open_issues/issue_tracking.mdwn b/open_issues/issue_tracking.mdwn
index 55c7b87b..72bb3b77 100644
--- a/open_issues/issue_tracking.mdwn
+++ b/open_issues/issue_tracking.mdwn
@@ -102,6 +102,84 @@ IRC, freenode, #hurd, 2011-08-31:
     <mattl> RT is not the easiest thing to set up, but works pretty well once
       it's running.
 
+IRC, freenode, #hurd, 2011-10-19:
+
+    <antrik> tschwinge: BTW, what happened to the plan of killing help-hurd?
+    <antrik> (and possibly some other lists)
+    <tschwinge> antrik: That plan got stalled, obviously.  ;-)
+    <tschwinge> antrik: Now, I had proposed to use hurd-dev for development,
+      and turn bug-hurd into a debbugs bug reportling list.  That proposal has
+      not heard any supportive/unsupportive votes yet.
+    <tschwinge> hurd-devel.  That's the name.
+    <tschwinge> And turn off hurd-devel-readers.  And turn off help-hurd.
+    <tschwinge> And web-hurd.
+    <tschwinge> Keep l4-hurd.
+    <antrik> yeah, I haven't replied regarding bug-hurd vs. hurd-devel, as I'm
+      not quite sure myself
+    <antrik> on one hand, a dedicated bug list can be convenient; on the other
+      hand, this kind of splits always causes unnecessary overhead IMHO
+    <antrik> also, hurd-devel would obviously be *only* for development, so in
+      this scenario we actually would *need* to keep something like help-hurd
+      as well...
+    <antrik> I think I'd prefer the non-exclusive mode for debbugs... would
+      have to check again how it works exactly though :-)
+    <tschwinge> antrik: I quite liked that exclusive mode for it automatically
+      archives discussions grouped by threads for easy reference.
+    <tschwinge> antrik: And, the very most of bug-hurd emails are ``issues'' of
+      some sort: bug report, patch (that needs to be tracked until it is
+      applied, etc.
+    <antrik> tschwinge: exclusive mode would just mean that people would take
+      most of these discussion elsewhere, and the bug list would only be used
+      when someone explicitly wants something tracked as a bug...
+    <antrik> ideally, the bug tracker should only track things if explicitly
+      CCed. ideally, it should be possible to forward mails that have been
+      posted without CC, so they can be tracked retroactively...
+    <tschwinge> antrik: Why do you think that people would take discussions
+      elsewhere?
+    <antrik> because most people don't consider it useful to put every random
+      question or remark in an issue tracker
+    <antrik> IMHO it should be easy to turn messages into tickets/followups;
+      but it should not happen automatically
+    <tschwinge> What if people wouldn't even notice that their issues is kept
+      in a tracker, too?
+    <draculus> It might send a notification of some sort?
+    <antrik> I once posted to a list with RT in exclusive mode, and quite
+      frankly, I considered it rather strange to get a ticket created for my
+      message :-)
+    <antrik> tschwinge: that would only be useful if you always close tickets
+      for irrelevant or finished discussions, mark duplicates etc. -- and this
+      would have to happen silently, without noise for most other people
+      following the list...
+    <antrik> tschwinge: are you sure you want to do that?... :-)
+    <tschwinge> Yes.
+    <tschwinge> Because that way we don't lose so much stuff as we currently
+      do.
+    <antrik> well, the decision is up to you in that case...
+    <tschwinge> In fact, probably less than manually archiving the content, as
+      I'm doing now, partially.
+    <tschwinge> antrik: Well, I'm just out for getting some comments.
+    <antrik> it would further reduce our bus factor though :-(
+    <tschwinge> That already is low enough that it doesn't matter anymore...
+    <tschwinge> antrik: So, to sum up, you'd use non-exclusive mode, but are
+      not actively opposed to exclusive mode as long as it doesn't too much
+      disturbe any procedures you're currently using?
+    <antrik> well, if it happens mostly in the background, I don't see why
+      anyone should be opposed...
+    <antrik> just make sure people posting to the list don't get a "ticket
+      created" message in response :-)
+    <antrik> it would make it harder though for people to explicitly track
+      issue they are interested in I fear
+    <antrik> when using non-exclusive mode, and people explicitly CC things to
+      the tracker, which sends a notice about a ticket being created, everyone
+      sees that and can act accordingly. if everything happens in the
+      background, few people would even think about it...
+    <antrik> so non-exclusive mode probably needs more effort to keep in order;
+      but it would be more useful too...
+    <tschwinge> Well, but with exclusive mode, people don't lose anything
+      compared to the current state, do they?
+    <antrik> tschwinge: probably not compared to the current state... but
+      possibly compared to a well-used non-exclusive mode :-)
+
 
 # Further Systems
 
diff --git a/open_issues/libpthread_assertion_thread_prevp.mdwn b/open_issues/libpthread_assertion_thread_prevp.mdwn
new file mode 100644
index 00000000..1418bea1
--- /dev/null
+++ b/open_issues/libpthread_assertion_thread_prevp.mdwn
@@ -0,0 +1,52 @@
+[[!meta copyright="Copyright © 2011 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: __pthread_enqueue: Assertion `thread->prevp == 0'
+failed"]]
+
+[[!tag open_issue_libpthread]]
+
+IRC, OFTC, #debian-hurd, 2011-10-21:
+
+    [Python testsuite]
+    <pinotree> [169/340/1] test_logging
+    <pinotree> python:
+      /home/pino/sources/hurd/hurd-20110519/./libpthread/pthread/pt-internal.h:109:
+      __pthread_enqueue: Assertion `thread->prevp == 0' failed.
+    <pinotree> sigh
+
+IRC, freenode, #hurd, 2011-10-21:
+
+    <pinotree> am i missing anything, or in libpthread the __pthread_threads
+      list does not ever has elements removed from it?
+    <pinotree> ... thus potentially causing
+      "./libpthread/pthread/pt-internal.h:109: __pthread_enqueue: Assertion
+      `thread->prevp == 0' failed." because threads can be appended on
+      __pthread_dealloc() to the __pthread_free_threads list as well?
+    <pinotree> maybe reusing the same next+prevp pointers in the __pthread
+      struct for more than one list at the same time isn't a good idea...
+
+2011-10-23:
+
+    <youpi> pinotree: I don't understand the relation between thread->prevp !=
+      0 and the __pthread_threads list
+    <youpi> the list never has elements removed indeed, since libpthread never
+      frees __pthread structures apparently
+    <pinotree> youpi: ye sorry, that relation is indeed nonsense
+    <youpi> in which condition did you get prevp != 0
+    <pinotree> i wa trying to find some explaination for the "thread->prevp ==
+      0" assertion in the _queue function
+    <youpi> ?
+    <pinotree> *was
+    <youpi> it's not obvious to me how libpthread makes sure the various
+      cond/mutex/rwlock make sure that it's not queued several times
+    <pinotree> yeah
+    <pinotree> apparently prevp/next are used for lists of held
+      waitcond/mutex/rwlock and free threads
diff --git a/open_issues/libpthread_pthread_key_create_reuse.mdwn b/open_issues/libpthread_pthread_key_create_reuse.mdwn
index a5704d0f..ca2da2f5 100644
--- a/open_issues/libpthread_pthread_key_create_reuse.mdwn
+++ b/open_issues/libpthread_pthread_key_create_reuse.mdwn
@@ -10,10 +10,10 @@ License|/fdl]]."]]"""]]
 
 [[!meta title="libpthread: pthread_key_create, reuse"]]
 
-IRC, FreeNode, #hurd, 2011-07-02
-
 [[!tag open_issue_libpthread]]
 
+IRC, FreeNode, #hurd, 2011-07-02:
+
     < pinotree> hm, maybe i found a libpthread bug
     * pinotree tries a testcase
     < pinotree> yesssss, found the bug :)
@@ -47,3 +47,36 @@ IRC, FreeNode, #hurd, 2011-07-02
       veeery quick glance
 
 Test program: [[pthread_key_create_reuse.c]]
+
+
+2011-11-01:
+
+    <pinotree> youpi: about the bug with pthread keys (reuse): would be an
+      acceptable solution having a mutex for the thread_specifics of each
+      thread?
+    <youpi> you mean one per thread, one global, or one per key, or ?
+    <youpi> what is it supposed to protect?
+    <pinotree> the thread_specifics of each thread
+    <youpi> pinotree: but against what?
+    <pinotree> the idea would be: when destroying a key, iterate over all the
+      exiting threads and remove the key data from the thread_specifics of each
+      thread
+    <youpi> one of the issue is getting to browse through the whole list of
+      threads
+    <youpi> the other is concurrency between that, and a thread dying
+    <pinotree> there's the __pthread_threads_lock rwlock
+    <youpi> it should be enough to keep it locked during the iteration
+    <pinotree> but that wouldn't be enough when one thread is destroying a key,
+      and another one is doing {get,set}specific() on that key
+    <youpi> that's not supposed to happen
+    <pinotree> mmm
+    <youpi> “The effect of calling pthread_getspecific() or
+      pthread_setspecific() with a     key value not obtained from
+      pthread_key_create() or after key has been     deleted with
+      pthread_key_delete() is undefined.”
+    <youpi> undefined -> you are allowed to just blow up
+    <pinotree> but it's not been deleted yet... :)
+    <youpi> it could be, just a matter of time
+    <youpi> you're not supposed to rely on time-luckyness :)
+    <pinotree> mmm
+    <pinotree> bah, you've convinced me ( :) )
diff --git a/open_issues/libpthread_set_stack_size.mdwn b/open_issues/libpthread_set_stack_size.mdwn
new file mode 100644
index 00000000..68f81752
--- /dev/null
+++ b/open_issues/libpthread_set_stack_size.mdwn
@@ -0,0 +1,25 @@
+[[!meta copyright="Copyright © 2011 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 open_issue_libpthread]]
+
+IRC, freenode, #hurd, 2011-10-21:
+
+    <pinotree> maybe i'm missing something... what's the reason for not
+      allowing setting a different stack size in libpthread?
+
+2011-10-23:
+
+    <youpi> pinotree: the threadvars implementations
+    <youpi> which needs to find the variables according to sp value
+    <youpi> of course, since we now have TLS, threadvards can go away
+    <youpi> it's simply on the so-long TODO list
+
+[[glibc/t/tls-threadvar]].
diff --git a/open_issues/mission_statement.mdwn b/open_issues/mission_statement.mdwn
new file mode 100644
index 00000000..212d65e7
--- /dev/null
+++ b/open_issues/mission_statement.mdwn
@@ -0,0 +1,39 @@
+[[!meta copyright="Copyright © 2011 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, 2011-10-12:
+
+    <ArneBab> we have a mission statement: http://hurd.gnu.org
+    <Gorodish> yes
+    <Gorodish> but it's quite wishy washy
+    <Gorodish> considering all the elegant capability Hurd potentially has to
+      offer
+    <antrik> Gorodish: it's true that the mission statement is very
+      abstract... but then, it's hard to put anything more specific into 35
+      words
+    <Gorodish> not with some practice
+    <Gorodish> I notice programers tend to speak and write in terms of what
+      something does
+    <Gorodish> not what it is
+    <Gorodish> the "What is Hurd" is a good example
+    <Gorodish> there's a lot of interesting information there
+    <Gorodish> but the way it's ordered is odd
+    <antrik> a mission statement is not primarily a PR instrument; but rather a
+      guide that allows separating things that benefit the common goal from
+      things that don't...
+    <antrik> I agree that some actual marketing material in addition would be
+      nice :-)
+    <Gorodish> yes
+    <Gorodish> the modesty of Developers that work on FOSS projects never
+      ceases to amaze me
+    <Gorodish> I agree that the informational, factual, results oriented
+      documentation is the primary objective of documenting
diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index 359d5fee..37fe9c53 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -27,6 +27,10 @@ extracted from cdf7c161ebd4a934c9e705d33f5247fd52975612 sources, 2010-10-24.
 On the idle grubber, this one repeatedly takes a few minutes wall time to
 complete successfully, contrary to a few seconds on a GNU/Linux system.
 
+> On order of slowness may in fact be due to a Xen-specific issue, see
+> [[xen_lseek]].  (But there are probably still one or two orders left, even
+> without Xen.)
+
 While processing the object files, there is heavy interaction with the relevant
 [[hurd/translator/ext2fs]] process.  Running [[hurd/debugging/rpctrace]] on
 the testee shows that (primarily) an ever-repeating series of `io_seek` and
diff --git a/open_issues/pfinet_vs_system_time_changes.mdwn b/open_issues/pfinet_vs_system_time_changes.mdwn
index 714c8784..513cbc73 100644
--- a/open_issues/pfinet_vs_system_time_changes.mdwn
+++ b/open_issues/pfinet_vs_system_time_changes.mdwn
@@ -17,7 +17,7 @@ IRC, unknown channel, unknown date.
 
 This was very likely a misdiagnosis:
 
-IRC, freenode, #hurd, 2011-03-25
+IRC, freenode, #hurd, 2011-03-25:
 
     <tschwinge> antrik: I suspect it'S some timing stuff in pfinet that perhaps
       uses absolute time, and somehow wildely gets confused?
@@ -40,3 +40,21 @@ IRC, freenode, #hurd, 2011-03-25
     <tschwinge> (The other way round, you might likely get some integer
       wrap-around, and thus the same result.)
     <tschwinge> Yes.
+
+IRC, freenode, #hurd, 2011-10-26:
+
+    <antrik> anyways, when ntpdate adjusts to the past, the connections hang,
+      roughly for the amount of time being adjusted
+    <antrik> they do not die though
+    <antrik> (well, if it's long enough, they probably timeout on the other
+      side...)
+
+IRC, freenode, #hurd, 2011-10-27:
+
+    <antrik> oh, another interesting thing I observed is that the the subhurd
+      pfinet did *not* drop the connection... only the main Hurd one. I thought
+      the clock is system-wide?...
+    <tschwinge> It is.
+    <antrik> it's really fascinating that only the pfinet on the Hurd instance
+      where I set the date is affected, and not the pfinet in the other
+      instance
diff --git a/open_issues/screen_dead_session.mdwn b/open_issues/screen_dead_session.mdwn
index cdd3f322..fe51523b 100644
--- a/open_issues/screen_dead_session.mdwn
+++ b/open_issues/screen_dead_session.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2010, 2011 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
@@ -14,7 +14,10 @@ Comparing to GNU/Linux, on GNU/Hurd it happens much more often and easily for
 *screen* sessions to become *dead*.  This is annoying, as it defeats one of
 *screen*'s main purposes.
 
-One reproducible scenario goes like this:
+[[!toc]]
+
+
+# One reproducible scenario goes like this
 
   * `ssh [somewhere]`,
 
@@ -28,7 +31,8 @@ One reproducible scenario goes like this:
   * at some point, *P* will terminate / hang (after having received some kind
     of signal?), and the *screen* session will be reported as *dead*.
 
-Another one, not as often reproduced:
+
+# Another one, not as often reproduced
 
   * `ssh [somewhere]`,
 
@@ -43,3 +47,23 @@ Another one, not as often reproduced:
     (after having received some kind of signal?), and the *screen* session will
     *immediatelly* be reported as *dead*.  (Perhaps the other way round: upon
     re-attaching, the *screen* session goes bonkers and takes *P* with it?)
+
+
+# IRC, freenode, #hurd, 2011-10-19
+
+    <antrik> tschwinge: hm... haven't seen screen dying in a long time
+    <tschwinge> antrik: It's easy, and goes like this: have a session on one
+      system, log in from another, do screen -x and wait some time.
+    <antrik> I do this regularily. haven't had a crash in ages.
+    <antrik> (BTW, I'm not sure I ever had a crash on srceen -x... at that
+      time, I wasn't using -x. I often had crashes with screen -r. my
+      impression back then was that it works better when doing -rd -- in fact,
+      I always do that now, so I can't say whether crashes still happen with
+      only -r...)
+
+2011-10-26:
+
+    <antrik> so I was saying the other day that I haven't had a screen crash in
+      a long time... well, here it was :-(
+    <antrik> this time it didn't crash on reconnect though, but already
+      before. probably when I killed the hanging ssh connection
diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn
index e929f2bf..70c3c6dc 100644
--- a/open_issues/user-space_device_drivers.mdwn
+++ b/open_issues/user-space_device_drivers.mdwn
@@ -97,7 +97,7 @@ IRC, freenode, #hurd, 2011-07-27
 
           * Hurd on L4: deva, fabrica
 
-          * [[DDE]]
+          * [[/DDE]]
 
       * Minix 3
 
@@ -195,7 +195,7 @@ IRC, freenode, #hurd, 2011-07-27
 
 # External Projects
 
-  * [[DDE]]
+  * [[/DDE]]
 
   * <http://ertos.nicta.com.au/research/drivers/uldd/>
 
diff --git a/open_issues/xen_lseek.mdwn b/open_issues/xen_lseek.mdwn
new file mode 100644
index 00000000..accc7c8f
--- /dev/null
+++ b/open_issues/xen_lseek.mdwn
@@ -0,0 +1,35 @@
+[[!meta copyright="Copyright © 2011 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_xen]]
+
+IRC, freenode, #hurd, 2011-11-02:
+
+    <youpi> btw, we have a performance issue with xen
+    <youpi> an lseek() call costs a huge lot
+    <youpi> like 1ms
+    <youpi> while the same costs just a few dozens µs with kvm
+    <youpi> there's of course the cost of switching between ring3, ring0,
+      ring1, ring0, ring3, but still
+    <gianluca> oh, nice.
+    <youpi> lseek is supposed to perform only a back&forth
+    <youpi> and I don't observe disk activity, so it's not waiting for the disk
+      to complete whatever atime change & such :)
+    <youpi> it was mentioned that perhaps xen in hvm mode with pv drivers would
+      be faster
+    <youpi> thanks to the ring3/"1" switching  being done by the processor
+    <youpi> (and assuming npt)
+    <gianluca> hm
+    <gianluca> i'll look into that, sounds fun.
+    <gianluca> :)
+    <tschwinge> Here is a testcase:
+      http://www.gnu.org/software/hurd/open_issues/performance/io_system/binutils_ld_64ksec.html
+
+[[performance/io_system/binutils_ld_64ksec]].
diff --git a/source_repositories/discussion.mdwn b/source_repositories/discussion.mdwn
new file mode 100644
index 00000000..ae64298e
--- /dev/null
+++ b/source_repositories/discussion.mdwn
@@ -0,0 +1,193 @@
+[[!meta copyright="Copyright © 2011 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]]."]]"""]]
+
+[[!toc]]
+
+
+# Integrating Development Braches/External Sources
+
+[[!taglink open_issue_documentation]]
+
+IRC, freenode, #hurd, 2011-10-11:
+
+    <tschwinge> braunr: About integrating salloc (I'll just use this name).
+    <tschwinge> braunr: Ideally, as this is an external import, there should be
+      an empty Git branch where the initial-import code (right out of your
+      tree, for example) is added.
+    <tschwinge> braunr: Then this is merged into a GNU Mach salloc branch and
+      moved into the destination directory.
+    <tschwinge> Then, any bug fix patches that do not concern salloc itself,
+      should stay separately.
+    <tschwinge> Also, any improvements that are not specific to salloc itself.
+    <tschwinge> All other salloc development commits (try this; no this; fix
+      other thing; etc.) can be combined into one commit on the salloc branch.
+    <tschwinge> Does that make sense?
+    <tschwinge> braunr: The idea of the separate external/braunr-salloc-import
+      branch is that any external updates are applied to this branch (where
+      they'll apply) cleanly, and then it is merged into GNU Mach salloc (or
+      later master, once salloc is merged) again.
+    <antrik> tschwinge: if you really want to use a branch for the external
+      code import, better actually import it with its history, not just as a
+      snapshot
+    <antrik> (disclaimer: haven't actually tried how well this works in
+      practice...)
+    <tschwinge> antrik: Yes, generally this is even better, but:
+    <tschwinge> antrik: But typically the external code we want to import is
+      just a subset of its external repository.  And I don't think we want to
+      have all of the external development history.
+    <antrik> that's the only sane way to do proper followup merges...
+    <antrik> admittedly it makes git log a bit confusing...
+    <tschwinge> antrik: Why is it the only sane way?
+    <braunr> tschwinge: "an empty Git branch", out of the gnumach git
+      repository ?
+    <braunr> tschwinge: then imported "into a GNU Mach salloc branch" ?
+    <antrik> tschwinge: otherwise you don't have merge history. you get no idea
+      why anything changed in the external code; and it's hard to merge any
+      changes happening in the local repository vs. the imports
+    <tschwinge> antrik: Of course, importing all the history may make sense at
+      times, but if we use the [Linux]/include/gcc-atomic.h header, we're
+      surely not going to import all the Linux kernel history for that.
+      Instead we would update our import branch with every upstream Linux
+      release, for example.
+    <tschwinge> braunr: You want me to clarify these points?
+    <braunr> tschwinge: yes please
+    <tschwinge> braunr: Start with an empty Git repository: mkdir import && cd
+      import/ && git init
+    <tschwinge> braunr: Add the files to-be-imported in there, adn commit that
+      as ``import ... version/Git commit from ...''.
+    <pinotree> tschwinge: maybe
+      http://book.git-scm.com/5_creating_new_empty_branches.html ?
+    <tschwinge> pinotree: Oh nice.
+    <tschwinge> pinotree: Thanks.
+    <pinotree> np
+    <tschwinge> Yes, can also do that, or a new Git repository as I said.
+    <tschwinge> braunr: Prefereably add the files in a salloc directory right
+      away to avoid any merge conflicts later on.
+    <tschwinge> braunr: Then, in GNU Mach, branch off of master: git checkout
+      -b salloc origin/master
+    <tschwinge> This will be the salloc integration working branch.
+    <tschwinge> braunr: Actually not ``in a salloc directory'', but with the
+      name the thing has in your upstream repository.
+    <tschwinge> Then, make the external import branch known here: git fetch
+      ../import master:external/import-braunr-allocator
+    <tschwinge> Then you can merge the external branch into the salloc branch:
+      git merge external/import-braunr-allocator
+    <braunr> got most of it, except for the "salloc directory"
+    <tschwinge> Then, move everything in place, and either commit --amend it to
+      the merge, or a separate commit.
+    <braunr> ah, you really suggest a separate directory not to have any
+      conflict
+    <braunr> then a move
+    <tschwinge> Right.
+    <braunr> but there maybe conflict afterwards
+    <tschwinge> I take it that the alloc files live in [x15]/kern/allocator, so
+      you'd put them into kern/allocator in the new repository, and then (after
+      merging that branch) move them to kern/salloc (or similar).
+    <braunr> i'm not sure i get the point
+    <braunr> no they won't
+    <braunr> it will live in kern/salloc.c, and the additional required files
+      like list.h may be put there too
+    <tschwinge> Aha, OK.
+    <braunr> but these are clearly separate files, so it should give the same
+      results, right ?
+    <tschwinge> Well, you could in the import branch put them all into x15/,
+      then merge, then move the files to kern/salloc.c, misc/list.h, etc.
+    <braunr> hm let's call it salloc/ :)
+    <braunr> but ok
+    <tschwinge> It's just that the import branch should have the same structure
+      than upstream has.
+    <tschwinge> To faciliate further imports later on.
+    <braunr> well, that's why i don't see the point of the move
+    <tschwinge> And after the merge it should have the file system structure as
+      used by GNU Mach.
+    <braunr> and there will be no upstream; once it's in gnu mach, it has its
+      own life
+    <tschwinge> Ah, OK.
+    <tschwinge> Well, then it won't matter too much.
+    <braunr> wouldn't it be better to make "upstream" (maskym's branch) have
+      the same structure as gnu mach already has before even creating the
+      integration branch ?
+    <tschwinge> I though X15 is the upstream.
+    <braunr> maksym*
+    <braunr> the upstream was actually the userspace library, before x15 got
+      its own derived version
+    <tschwinge> OK, I see.
+    <tschwinge> Then we really don't care too much, and yes, you can put it all
+      in the right places right away.
+    <braunr> ok
+    <tschwinge> But is my approach understandable given there is an upstream
+      from which we may want to import later changes?
+    <tschwinge> given there *were*
+    <braunr> (fyi, the userspace code was merely a first step which purpose was
+      to eliminate as many bugs as possible and profile a little)
+    <braunr> i don't intend to maintain the userspace code, no
+    <braunr> and the x15 version already has some system specific changes that
+      don't apply to gnu mach
+    <tschwinge> OK, I understand.
+    <tschwinge> braunr: Then, what remains is essentially this:
+    <tschwinge> <tschwinge> Then, any bug fix patches that do not concern
+      salloc itself, should stay separately.
+    <tschwinge> <tschwinge> Also, any improvements that are not specific to
+      salloc itself.
+    <tschwinge> <tschwinge> All other salloc development commits (try this; no
+      this; fix other thing; etc.) can be combined into one commit on the
+      salloc branch.
+    <tschwinge> Right?
+    <braunr> ok
+    <braunr> hm, what about the history of maksym's branch ?
+    <tschwinge> braunr: We don't really need it, do we?
+    <tschwinge> If there are distinct commits that make sense to be kept
+      separate, then that is fine, but all the development commits can usually
+      be merged.
+    <tschwinge> ``squashed''
+    <braunr> i don't think we do, no
+    <braunr> ok so, i'll use his branch as a starting point in a private git
+      repository, until it's good enough to be merged upstream, then we'll
+      create the salloc integration branch and later merge that into master
+    <braunr> tschwinge: did i get it right ? :)
+    <tschwinge> We can still either keep Maksym's development branch open, or
+      perhaps create a tag named salloc-before-merge.
+    <tschwinge> Well, I think if we don't need to do the upstream-import thing,
+      then you can create a salloc integration branch right away, and prepare
+      everything in there.
+    <braunr> ok
+    <braunr> i'm not very familiar with remote branches
+    <tschwinge> OK.  This way you don't need any.
+    <tschwinge> Just branch off of master (either your local master branch or
+      origin/master): git checkout -b salloc origin/master
+    <antrik> braunr: BTW, I'm not sure it has been clear, so let me restate it:
+      what large projects using Git usually do when merging new features
+      upstream is, they entirely drop the development history of the feature,
+      instead creating a new branch (or reworking the old one) which is
+      master-centric -- it is a series of commits, which get from the original
+      master to a state with the new feature implemented in the most
+      straightforward way
+    <braunr> antrik: in one commit ?
+    <braunr> antrik: or a few ofc
+    <antrik> depends. the commits should be bisectable as usual... i.e. don't
+      put things that can be separate into one commit, but don't separate
+      things that depend on each other into separate commits either :-)
+    <antrik> the bulk of the new code often goes in single large commit; but
+      the various changes to existing code necessary to make it work can often
+      make a pretty long series. but it can differ quite a lot depending on the
+      specific case
+    <antrik> just imagine you are someone reading the history in the future,
+      and tries to understand what changed while zalloc was replaced by
+      salloc. what series of commits makes this most obvious?
+    <braunr> sure
+    <braunr> antrik: new code first in a single commit first, then the
+      replacements from zalloc to salloc, then if any, special adjustements in
+      a third commit
+    <braunr> (ok twice first, remove one at will :p)
+    <antrik> yeah, something along these lines
+    <antrik> sometimes we also need praparation commits in advance, changing
+      the code structure so that the new feature can be added in a
+      straightforward fashion
+    <antrik> or cleanups afterwards
-- 
cgit v1.2.3


From e640b97228bd1214a4dc37ac9d79a704acd40c0c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Fri, 4 Nov 2011 22:53:40 +0100
Subject: open_issues/ti-rpc_then_nfs: id:"87hb2j7ha7.fsf@gnu.org"

---
 open_issues/ti-rpc_then_nfs.mdwn | 20 ++++++++++++++++++++
 1 file changed, 20 insertions(+)
 create mode 100644 open_issues/ti-rpc_then_nfs.mdwn

(limited to 'open_issues')

diff --git a/open_issues/ti-rpc_then_nfs.mdwn b/open_issues/ti-rpc_then_nfs.mdwn
new file mode 100644
index 00000000..aa36e020
--- /dev/null
+++ b/open_issues/ti-rpc_then_nfs.mdwn
@@ -0,0 +1,20 @@
+[[!meta copyright="Copyright © 2011 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_hurd open_issue_porting]]
+
+TI-RPC replaces glibc's Sun RPC implementation, [[!message-id
+"4D0632C5.1040107@RedHat.com"]].
+
+It needs some work on our side, [[!message-id
+"20101214213212.GU1095@kepler.schwinge.homeip.net"]].
+
+Then, the Hurd's [[hurd/translator/nfs]] translator and [[hurd/nfsd]] can be
+re-enabled, [[!message-id "87hb2j7ha7.fsf@gnu.org"]].
-- 
cgit v1.2.3


From ad0f2aa843232649166e0252e28b96c1736c5082 Mon Sep 17 00:00:00 2001
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Wed, 2 Nov 2011 12:48:18 +0100
Subject: Add lseek/mach testcases

---
 .../performance/io_system/binutils_ld_64ksec.mdwn      |  2 ++
 open_issues/performance/io_system/test-lseek.c         | 16 ++++++++++++++++
 open_issues/performance/io_system/test-mach.c          | 18 ++++++++++++++++++
 3 files changed, 36 insertions(+)
 create mode 100644 open_issues/performance/io_system/test-lseek.c
 create mode 100644 open_issues/performance/io_system/test-mach.c

(limited to 'open_issues')

diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
index 359d5fee..39d95349 100644
--- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
+++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn
@@ -47,4 +47,6 @@ IRC, freenode, #hurd, 2011-09-01:
     <youpi> (fgetpos actually, but that's the same)
     <youpi> and it is indeed about 10 times slower under Xen for some reason
 
+Also see testcase [[test-lseek.c]] and [[test-mach.c]]
+
 [[!tag open_issue_xen]]
diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c
new file mode 100644
index 00000000..691e9d07
--- /dev/null
+++ b/open_issues/performance/io_system/test-lseek.c
@@ -0,0 +1,16 @@
+#include <stdio.h>
+#include <math.h>
+#include <fcntl.h>
+#include <unistd.h>
+#include <sys/time.h>
+int main(void) {
+	int fd = open("test.c", O_RDONLY);
+	struct timeval tv1, tv2;
+	int i;
+	gettimeofday(&tv1, NULL);
+	for (i = 0; i < 100000; i++)
+		lseek(fd, 0, SEEK_CUR);
+	gettimeofday(&tv2, NULL);
+	printf("%07lu\n", (tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec);
+	return 0;
+}
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c
new file mode 100644
index 00000000..44f62a4e
--- /dev/null
+++ b/open_issues/performance/io_system/test-mach.c
@@ -0,0 +1,18 @@
+#define _GNU_SOURCE
+#include <stdio.h>
+#include <fcntl.h>
+#include <mach/mach.h>
+int main(void) {
+	struct timeval tv1, tv2;
+	int i;
+	task_t task;
+	task = mach_task_self();
+	mach_port_urefs_t refs;
+	gettimeofday(&tv1, NULL);
+	for (i = 0; i < 1000000; i++) {
+		mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs);
+	}
+	gettimeofday(&tv2, NULL);
+	printf("%07lu\n", (tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec);
+	return 0;
+}
-- 
cgit v1.2.3


From 2e315ef11db39e8ee0a0decc054801521ee049dd Mon Sep 17 00:00:00 2001
From: Samuel Thibault <samuel.thibault@ens-lyon.org>
Date: Sat, 5 Nov 2011 15:23:57 +0100
Subject: better formatting

---
 open_issues/performance/io_system/test-lseek.c | 5 +++--
 open_issues/performance/io_system/test-mach.c  | 5 +++--
 2 files changed, 6 insertions(+), 4 deletions(-)

(limited to 'open_issues')

diff --git a/open_issues/performance/io_system/test-lseek.c b/open_issues/performance/io_system/test-lseek.c
index 691e9d07..667dce66 100644
--- a/open_issues/performance/io_system/test-lseek.c
+++ b/open_issues/performance/io_system/test-lseek.c
@@ -3,14 +3,15 @@
 #include <fcntl.h>
 #include <unistd.h>
 #include <sys/time.h>
+#define N 100000
 int main(void) {
 	int fd = open("test.c", O_RDONLY);
 	struct timeval tv1, tv2;
 	int i;
 	gettimeofday(&tv1, NULL);
-	for (i = 0; i < 100000; i++)
+	for (i = 0; i < N; i++)
 		lseek(fd, 0, SEEK_CUR);
 	gettimeofday(&tv2, NULL);
-	printf("%07lu\n", (tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec);
+	printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N);
 	return 0;
 }
diff --git a/open_issues/performance/io_system/test-mach.c b/open_issues/performance/io_system/test-mach.c
index 44f62a4e..90337346 100644
--- a/open_issues/performance/io_system/test-mach.c
+++ b/open_issues/performance/io_system/test-mach.c
@@ -2,6 +2,7 @@
 #include <stdio.h>
 #include <fcntl.h>
 #include <mach/mach.h>
+#define N 1000000
 int main(void) {
 	struct timeval tv1, tv2;
 	int i;
@@ -9,10 +10,10 @@ int main(void) {
 	task = mach_task_self();
 	mach_port_urefs_t refs;
 	gettimeofday(&tv1, NULL);
-	for (i = 0; i < 1000000; i++) {
+	for (i = 0; i < N; i++) {
 		mach_port_get_refs(task, task, MACH_PORT_RIGHT_RECEIVE, &refs);
 	}
 	gettimeofday(&tv2, NULL);
-	printf("%07lu\n", (tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec);
+	printf("%fµs\n", (float)((tv2.tv_sec-tv1.tv_sec) * 1000000 + tv2.tv_usec - tv1.tv_usec)/N);
 	return 0;
 }
-- 
cgit v1.2.3