Been reading another LWN issue...

7 files changed, 128 insertions, 8 deletions

diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn
index 98447e98..ad104e68 100644
--- a/open_issues/code_analysis.mdwn
+++ b/open_issues/code_analysis.mdwn
@@ -8,7 +8,7 @@ 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]]."]]"""]]
 
-There is static and dynamic code analysis.
+There is static and dynamic code analysis.  This overlaps with [[debugging]].
 
   * [[GCC]]'s warnings.  Yes, really.
 
@@ -29,3 +29,13 @@ There is static and dynamic code analysis.
   * <http://klee.llvm.org/>
 
       * <http://blog.llvm.org/2010/04/whats-wrong-with-this-code.html>
+
+  * [[Valgrind]]
+
+  * <http://en.wikipedia.org/wiki/Electric_Fence>
+
+      * <http://sourceforge.net/projects/duma/>
+
+  * <http://wiki.debian.org/Hardening>
+
+  * <https://wiki.ubuntu.com/CompilerFlags>
diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn
index 95b7bf9b..e66a086f 100644
--- a/open_issues/debugging.mdwn
+++ b/open_issues/debugging.mdwn
@@ -18,7 +18,7 @@ We have debugging infrastructure.  For example:
   * [[GNU Mach debugging|microkernel/mach/gnumach/debugging]]
 
   * [[GNU Hurd debugging|hurd/debugging]], including
-    [[hurd/debugging/rpctrace]] and more.
+    [[hurd/debugging/rpctrace]], and more.
 
 
 # To Do
@@ -29,14 +29,20 @@ We have debugging infrastructure.  For example:
 
   * [[profiling]]
 
-  * *[Checkpoint/restart](http://lwn.net/Articles/412749/) allows the state of
-    a set of processes to be saved to persistent storage, then restarted at
-    some future time* -- quoting from Jonathan Corbet's 2010 Linux Kernel
-    Summit report.
+  * *Checkpoint/restart allows the state of a set of processes to be saved to
+    persistent storage, then restarted at some future time* -- quoting from
+    Jonathan Corbet's [2010 Linux Kernel Summit
+    report](http://lwn.net/Articles/412749/).
 
     This is surely a very useful facility to have for reproducing failures, for
     example.  But on the other hand it's questionable how it can help with
     debugging failures in [[GNU Hurd server|hurd/translator]]s' interactions,
     as their state is typically spread between several processes.
 
+    Continues: <http://lwn.net/Articles/414264/>, which introduces
+    <http://dmtcp.sourceforge.net/>.
+
   * [[locking]]
+
+  * <http://lwn.net/Articles/415728/>, or <http://lwn.net/Articles/415471/> --
+    just two examples; there's a lot of such stuff for Linux.
diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn
index 81b96280..170734fd 100644
--- a/open_issues/multithreading.mdwn
+++ b/open_issues/multithreading.mdwn
@@ -22,9 +22,11 @@ Alternative approaches:
 
   * Continuation-passing style
 
+  * [[Erlang-style_parallelism]]
+
   * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/)
 
-  * [[Erlang-style_parallelism]]
+  * <http://monkey.org/~provos/libevent/>
 
 ---
 
diff --git a/open_issues/nightly_builds_deb_packages.mdwn b/open_issues/nightly_builds_deb_packages.mdwn
index 29219c2a..9f5e2373 100644
--- a/open_issues/nightly_builds_deb_packages.mdwn
+++ b/open_issues/nightly_builds_deb_packages.mdwn
@@ -18,4 +18,10 @@ packages.
 
 ---
 
+There is infrastructure available to test whole OS installations.
+
+  * <http://www.os-autoinst.org/>
+
+---
+
 See also [[nightly_builds]].
diff --git a/open_issues/secure_file_descriptor_handling.mdwn b/open_issues/secure_file_descriptor_handling.mdwn
index c9956ede..1a514e69 100644
--- a/open_issues/secure_file_descriptor_handling.mdwn
+++ b/open_issues/secure_file_descriptor_handling.mdwn
@@ -8,7 +8,16 @@ 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]]
+
 `O_CLOEXEC`, `dup3` et al.; see
 <http://udrepper.livejournal.com/20407.html>.  [[tschwinge]] once worked
 on this, posted patches to libc-alpha.  This works needs to be resumed
 and finished.
+
+---
+
+In <http://lwn.net/Articles/417421/> an interesting point is made: *you [may]
+want some [[unix/file_descriptor]] to still be open if 'exec' fails, but you
+don't want it to be open after the exec succeeds*.  [[I|tschwinge]]'m not sure
+whether our current `O_CLOEXEC` implementation adheres to that.
diff --git a/open_issues/unit_testing.mdwn b/open_issues/unit_testing.mdwn
index 80a2860a..d50f5f6d 100644
--- a/open_issues/unit_testing.mdwn
+++ b/open_issues/unit_testing.mdwn
@@ -46,7 +46,14 @@ abandoned).
 
   * [*[ANNOUNCE] ktest.pl: Easy and flexible testing script for Linux Kernel
     Developers*](http://lwn.net/Articles/412302/) by Steven Rostedt,
-    2010-10-28.
+    2010-10-28.  [v2](http://lwn.net/Articles/414064/), 2010-11-08.
+
+
+# Related
+
+  * [[nightly_builds]]
+
+      * [[nightly_builds_deb_packages]]
 
   * <http://www.phoronix-test-suite.com/> -- ``comprehensive testing and
     benchmarking platform''.  This one might be useful for [[performance]]
diff --git a/open_issues/valgrind.mdwn b/open_issues/valgrind.mdwn
new file mode 100644
index 00000000..2b0624d7
--- /dev/null
+++ b/open_issues/valgrind.mdwn
@@ -0,0 +1,80 @@
+[[!meta copyright="Copyright © 2009, 2010 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="Porting Valgrind to the Hurd"]]
+
+[Valgrind](http://valgrind.org/) is an extremely useful debugging tool for memory errors.
+(And some other kinds of hard-to-find errors too.)
+Aside from being useful for program development in general,
+a Hurd port will help finding out why certain programs segfault on the Hurd,
+although they work on Linux.
+Even more importantly, it will help finding bugs in the Hurd servers themselfs.
+
+To keep track of memory use,
+Valgrind however needs to know how each [[system call]] affects the validity of memory regions.
+This knowledge is highly kernel-specific,
+and thus Valgrind needs to be explicitely ported for every system.
+
+Such a port involves two major steps:
+making Valgrind understand how kernel traps work in general on the system in question;
+and how all the individual kernel calls affect memory.
+The latter step is where most of the work is,
+as the behaviour of each single [[system call]] needs to be described.
+
+Compared to Linux,
+[[microkernel/Mach]] (the microkernel used by the Hurd) has very few kernel traps.
+Almost all [[system call]]s are implemented as [[RPC]]s instead --
+either handled by Mach itself, or by the various [[Hurd servers|hurd/translator]].
+All RPCs use a pair of `mach_msg` invocations:
+one to send a request message, and one to receive a reply.
+However, while all RPCs use the same `mach_msg` trap,
+the actual effect of the call varies greatly depending on which RPC is invoked --
+similar to the `ioctl` call on Linux.
+Each request thus must be handled individually.
+
+Unlike `ioctl`,
+the RPC invocations have explicit type information for the parameters though,
+which can be retrieved from the message header.
+By analyzing the parameters of the RPC reply message,
+Valgrind can know exactly which memory regions are affected by that call,
+even without specific knowledge of the RPC in question.
+Thus implementing a general parser for the reply messages
+will already give Valgrind a fairly good approximation of memory validity --
+without having to specify the exact semantic of each RPC by hand.
+
+While this should make Valgrind quite usable on the Hurd already, it's not perfect:
+some RPCs might return a buffer that is only partially filled with valid data;
+or some reply parameters might be optional,
+and only contain valid data under certain conditions.
+Such specific semantics can't be deduced from the message headers alone.
+Thus for a complete port,
+it will still be necessary to go through the list of all known RPCs,
+and implement special handling in Valgrind for those RPCs that need it.
+
+The goal of this task is at minimum to make Valgrind grok Mach traps,
+and to implement the generic RPC handler.
+Ideally, specific handling for RPCs needing it should also be implemented.
+
+Completing this project will require digging into Valgrind's handling of [[system call]]s,
+and into Hurd RPCs.
+It is not an easy task, but a fairly predictable one --
+there shouldn't be any unexpected difficulties,
+and no major design work is necessary.
+It doesn't require any specific previous knowledge:
+only good programming skills in general.
+On the other hand,
+the student will obtain a good understanding of Hurd RPCs while working on this task,
+and thus perfect qualifications for Hurd development in general :-)
+
+Possible mentors: Samuel Thibault (youpi)
+
+Exercise: As a starter,
+students can try to teach valgrind a couple of Linux ioctls,
+as this will make them learn how to use the read/write primitives of valgrind.