From cd782d77c1e90976cb6dacf6ba78ba762f145a50 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 30 Nov 2010 10:39:28 +0100 Subject: Been reading another LWN issue... --- open_issues/code_analysis.mdwn | 12 +++- open_issues/debugging.mdwn | 16 +++-- open_issues/multithreading.mdwn | 4 +- open_issues/nightly_builds_deb_packages.mdwn | 6 ++ open_issues/secure_file_descriptor_handling.mdwn | 9 +++ open_issues/unit_testing.mdwn | 9 ++- open_issues/valgrind.mdwn | 80 ++++++++++++++++++++++++ 7 files changed, 128 insertions(+), 8 deletions(-) create mode 100644 open_issues/valgrind.mdwn (limited to 'open_issues') 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. * * + + * [[Valgrind]] + + * + + * + + * + + * 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: , which introduces + . + * [[locking]] + + * , or -- + 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]] + * --- 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. + + * + +--- + 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 . [[tschwinge]] once worked on this, posted patches to libc-alpha. This works needs to be resumed and finished. + +--- + +In 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]] * -- ``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. -- cgit v1.2.3