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... --- capability.mdwn | 14 ++-- community/gsoc/project_ideas.mdwn | 2 +- community/gsoc/project_ideas/valgrind.mdwn | 80 ---------------------- glibc.mdwn | 9 ++- glibc/fallocate.mdwn | 17 +++++ glibc/fork.mdwn | 18 +++-- glibc/signals.mdwn | 32 +++++++++ hurd/glibc/hurd-specific_api.mdwn | 8 ++- hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 24 ++++--- hurd/translator/magic.mdwn | 11 +-- 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 ++++++++++++++++++++++ persistency.mdwn | 11 +-- unix.mdwn | 48 +++++++++++-- unix/file_descriptor.mdwn | 13 ++++ virtualization.mdwn | 7 +- 21 files changed, 296 insertions(+), 134 deletions(-) delete mode 100644 community/gsoc/project_ideas/valgrind.mdwn create mode 100644 glibc/fallocate.mdwn create mode 100644 glibc/signals.mdwn create mode 100644 open_issues/valgrind.mdwn create mode 100644 unix/file_descriptor.mdwn diff --git a/capability.mdwn b/capability.mdwn index 367ea163..d78810d5 100644 --- a/capability.mdwn +++ b/capability.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A capability is a protected reference. It is a reference in that it designates an object; it is protected in that in cannot be @@ -27,7 +28,6 @@ sent a string to identify the file to B, the identifier lacks a than A intended. Be ensuring that [[designation]] and [[authorization]] are always bound together, these problems are avoided. -[[Unix]] file descriptors can be viewed as capabilities. Unix file -descriptors do not survive reboot, that is, they are not -[[persistent|persistency]]. To work around this, [[ACL]]s are used to -recover authority. +[[UNIX file descriptors|unix/file_descriptor]] can be viewed as capabilities. +They do not survive reboot, that is, they are not [[persistent|persistency]]. +To work around this, [[ACL]]s are used to recover authority. diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index b039608f..649e05c1 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -106,4 +106,4 @@ See also the list of [Hurd-related X.org project ideas](http://wiki.x.org/wiki/H [[!inline pages="community/gsoc/project_ideas/testsuites" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/libcap" show=0 feeds=no actions=yes]] [[!inline pages="community/gsoc/project_ideas/xattr" show=0 feeds=no actions=yes]] -[[!inline pages="community/gsoc/project_ideas/valgrind" show=0 feeds=no actions=yes]] +[[!inline pages="open_issues/valgrind" show=0 feeds=no actions=yes]] diff --git a/community/gsoc/project_ideas/valgrind.mdwn b/community/gsoc/project_ideas/valgrind.mdwn deleted file mode 100644 index 7d68e82d..00000000 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ /dev/null @@ -1,80 +0,0 @@ -[[!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, -Mach (the microkernel used by the Hurd) has very few kernel traps. -Almost all [[system call]]s are implemented as RPCs instead -- -either handled by Mach itself, or by the various Hurd servers. -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. diff --git a/glibc.mdwn b/glibc.mdwn index 2eba3667..124216d9 100644 --- a/glibc.mdwn +++ b/glibc.mdwn @@ -36,11 +36,18 @@ Porting glibc to a specific architecture is non-trivial. * [[open_issues/secure_file_descriptor_handling]] +## Concepts + + * [[environment_variables]] + + * [[signals]] + + ## Individual functions Some of these are well-known as [[UNIX]] [[system call]]s. - * [[environment_variables]] + * [[fallocate]] * [[fork]] diff --git a/glibc/fallocate.mdwn b/glibc/fallocate.mdwn new file mode 100644 index 00000000..3aecf16b --- /dev/null +++ b/glibc/fallocate.mdwn @@ -0,0 +1,17 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +Not yet implemented for the GNU Hurd in [[glibc]]. + + +# External + + * [*Punching holes in files*](http://lwn.net/Articles/415889/), Jonathan + Corbet, 2010-11-17. diff --git a/glibc/fork.mdwn b/glibc/fork.mdwn index e8556a91..378fe835 100644 --- a/glibc/fork.mdwn +++ b/glibc/fork.mdwn @@ -14,10 +14,10 @@ Our implementation in [[glibc]] is and needs to be rather bulky. For example, it has to duplicate all port rights for the new [[Mach task|microkernel/mach/task]]. The address space can simply be duplicated by -standard means of the [[microkernel/Mach]], but as [[file descriptor]]s (for -example) are a concept that is implemented inside [[glibc]] (based on [[Mach -port|microkernel/mach/port]]s), these have to be duplicated from userspace, -which requires a small number of [[RPC]] for each of them. +standard means of the [[microkernel/Mach]], but as [[unix/file_descriptor]]s +(for example) are a concept that is implemented inside [[glibc]] (based on +[[Mach port|microkernel/mach/port]]s), these have to be duplicated from +userspace, which requires a small number of [[RPC]] for each of them. In sum, [[this affects performance|open_issues/performance/fork]] when new processes are continuously being spawned from the shell, for example. @@ -43,7 +43,7 @@ they have patches for software packages, to avoid using `fork` followed by ([[!taglink open_issue_glibc]]). * Include de-duplicate information from elsewhere: [[hurd-paper]], - [[hurd-talk]] [[hurd/ng/trivialconfinementvsconstructorvsfork]], + [[hurd-talk]], [[hurd/ng/trivialconfinementvsconstructorvsfork]], [[open_issues/resource_management_problems/zalloc_panics]] ([[!taglink open_issue_glibc open_issue_documentation]]). @@ -54,13 +54,11 @@ they have patches for software packages, to avoid using `fork` followed by ## Related - * [[secure file descriptor handling]]. + * [[open_issues/secure_file_descriptor_handling]]. # External - * [*How fork(2) ought to be*](http://www.greenend.org.uk/rjk/fork.html) by - Richard Kettlewell. + * {{$unix#djb_self-pipe}}. - * [*The self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) by - D. J. Bernstein. + * {{$unix#rjk_fork}}. diff --git a/glibc/signals.mdwn b/glibc/signals.mdwn new file mode 100644 index 00000000..40fdc0e1 --- /dev/null +++ b/glibc/signals.mdwn @@ -0,0 +1,32 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +*[[UNIX]] signals* are a means to asynchronously invoke a specific function +(*signal handler*). This may impact on [[system call]]s that are executing at +the same time in that they may be completely aborted, return incomplete +results, scheduled for restarting, or cause signal delivery to be blocked upon +the system call's completion. + +An explanation can be found in the relevant standards, an overview, including +UNIX signals' deficiencies is given in {{$unix#2010_brown_ghosts_3}}, for +example. + +The UNIX signalling mechanism is implemented for the GNU Hurd by means of a +separate signal-handling thread that is part of every process. This makes +handling of signals a separate thread of control. + + * [[SA_SIGINFO, SA_SIGACTION|open_issues/sa_siginfo_sa_sigaction]] + + +# External + + * {{$unix#djb_self-pipe}}. + + * {{$unix#rjk_fork}}. diff --git a/hurd/glibc/hurd-specific_api.mdwn b/hurd/glibc/hurd-specific_api.mdwn index 75220279..7ead63cd 100644 --- a/hurd/glibc/hurd-specific_api.mdwn +++ b/hurd/glibc/hurd-specific_api.mdwn @@ -82,7 +82,13 @@ programs -- they are used to produce `.h` files.
openport (io_t port, int flags);

-
Open a file descriptor on a port. FLAGS are as for open; flags affected by io_set_openmodes are not changed by this. If successful, this consumes a user reference for PORT (which will be deallocated on close.) See <hurd/io.defs> and <hurd/io.h>.
+
Open a [[unix/file_descriptor]] on a [[microkernel/mach/port]]. FLAGS + are as for open; flags affected by io_set_openmodes are + not changed by this. If successful, this consumes a user reference for + PORT (which will be deallocated on close.) See + <hurd/io.defs> and + <hurd/io.h>. +

task_t
diff --git a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn index 0d91dee7..949895e7 100644 --- a/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn +++ b/hurd/ng/trivialconfinementvsconstructorvsfork.mdwn @@ -34,15 +34,15 @@ This mechanism is targeted at a specific use pattern, namely that a process is c # POSIX Fork POSIX fork, or rather fork+exec, is how things are done on many current -systems. It may be insightful to see it included in the comparison, especially -for people who are new to the subject. There are two [[system call]]s, fork and -exec. Fork will create a clone of the current process, including all the -capabilities (that is, file descriptors) of the parent (except the ones which -have explicitly been excluded). Exec is a [[system call]] which really goes to -the filesystem, not the kernel (although on systems which use it, the -filesystem usually resides in the kernel), and asks it to spawn a new process -from the contents of a certain path in place of the caller. This passes all -capabilities to the new process. The procedure is: +systems. It may be insightful to see it included in the comparison, especially +for people who are new to the subject. There are two [[system call]]s, fork +and exec. Fork will create a clone of the current process, including all the +capabilities (that is, [[unix/file_descriptor]]s) of the parent (except the +ones which have explicitly been excluded). Exec is a [[system call]] which +really goes to the filesystem, not the kernel (although on systems which use +it, the filesystem usually resides in the kernel), and asks it to spawn a new +process from the contents of a certain path in place of the caller. This +passes all capabilities to the new process. The procedure is: * P calls fork(), creating P'. * P' drops B. @@ -62,7 +62,11 @@ In contrast, the other two options don't pass anything by default. If there is a The problem of fork+exec can be solved. It is if the default would be to not pass capabilities to the new process, but specify a list of capabilities that it should keep, or (like in the other cases) pass them over a new channel which is implicitly created during the fork. However, in that case the only difference with trivial confinement is that P' dies in the process (and thus must be created to prevent P from dying). Almost any use of exec is in practice preceded by a fork for this purpose. It would be easier to make trivial confinement the default operation and let P die directly after it in the rare case that it should. -The only reason for continuing to use fork+exec would be that it is what existing programs do. However, they break anyway if they need to specify which file descriptors to pass. So they need to be adapted. Therefore, it's better to make the usual spawning method the primitive one, and emulate the other. +The only reason for continuing to use fork+exec would be that it is what +existing programs do. However, they break anyway if they need to specify which +[[unix/file_descriptor]]s to pass. So they need to be adapted. Therefore, it's +better to make the usual spawning method the primitive one, and emulate the +other. # Trivial Confinement vs Constructor diff --git a/hurd/translator/magic.mdwn b/hurd/translator/magic.mdwn index 06ee798b..84bacdfb 100644 --- a/hurd/translator/magic.mdwn +++ b/hurd/translator/magic.mdwn @@ -1,20 +1,21 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2006, 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] The magic translator provides `/dev/fd`. $ showtrans /dev/fd /hurd/magic --directory fd -The `/dev/fd` directory holds the open file descriptors for your current -process. You can't see them with `ls -l /dev/fd/` but you can see them +The `/dev/fd` directory holds the open [[unix/file_descriptor]]s for your +current process. You can't see them with `ls -l /dev/fd/` but you can see them individually like this: $ ls -l /dev/fd/0 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. diff --git a/persistency.mdwn b/persistency.mdwn index f5347a4e..36f90c8a 100644 --- a/persistency.mdwn +++ b/persistency.mdwn @@ -1,18 +1,19 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] A persistent object is an object that survives reboot. On [[Unix]], files and directories are persistent but -processes and file descriptors are not. [[microkernel/EROS]] is +processes and [[unix/file_descriptor]]s are not. [[microkernel/EROS]] is an example of an orthogonally persistent system: -processes and capabilities also survive reboot. To a +processes and [[capabilities|capability]] also survive reboot. To a process, it generally only looks as if it had not been scheduled for a long time; the rest of its environment remains essentially the indistinguishable. diff --git a/unix.mdwn b/unix.mdwn index 601b36d1..bf361e2e 100644 --- a/unix.mdwn +++ b/unix.mdwn @@ -19,9 +19,49 @@ License|/fdl]]."]]"""]] UNIX*](http://www.informit.com/articles/printerfriendly.aspx?p=691503), an article by David Chisnall. - * [*Ghosts of Unix Past: a historical search for design - patterns*](http://lwn.net/Articles/411845/) (2010-10-27) by Neil Brown, - including file descriptors and the single, hierarchical namespace. + * The first in the series, {{$2010_brown_ghosts_1}} introduces the concepts + of [[file_descriptor]]s and the single, hierarchical [[namespace]]. + + Next, {{$2010_brown_ghosts_2}} discusses issues with *conflated designs* + such as the `mount` command (a problem we have partly solved / solved + differently with our [[hurd/translator]] approach and the + [[hurd/virtual_file_system]]), and the plethora of flags that can be passed + to the `open` [[system_call]]. + + In {{$2010_brown_ghosts_3}}, he deals with *unfixable designs*, such as + [[UNIX signals|glibc/signals]] and the *UNIX permission model* (which is + clearly inferior to a [[capability]]-based system). * [*UNIX File Permissions*](http://www.greenend.org.uk/rjk/2004/perms.html) - (2004) by Richard Kettlewell. + (2004) by Richard Kettlewell. ([[!taglink open_issue_documentation]]) + + +[[!ymlfront data=""" + +djb_self-pipe: + + D. J. Bernstein's [*self-pipe trick*](http://cr.yp.to/docs/selfpipe.html) + +rjk_fork: + + Richard Kettlewell's suggestions about [*how fork(2) ought to + be*](http://www.greenend.org.uk/rjk/fork.html) + +2010_brown_ghosts_1: + + "Neil Brown's 2010-10-27 article [*Ghosts of Unix Past: a historical search + for design patterns*](http://lwn.net/Articles/411845/)" + +2010_brown_ghosts_2: + + "Neil Brown's 2010-11-04 article [*Ghosts of Unix past, part 2: Conflated + designs*](http://lwn.net/Articles/412131/)" + +2010_brown_ghosts_3: + + "Neil Brown's 2010-11-16 article [*Ghosts of Unix past, part 3: Unfixable + designs*](http://lwn.net/Articles/414618/)" + +"""]] diff --git a/unix/file_descriptor.mdwn b/unix/file_descriptor.mdwn new file mode 100644 index 00000000..16e03fdf --- /dev/null +++ b/unix/file_descriptor.mdwn @@ -0,0 +1,13 @@ +[[!meta copyright="Copyright © 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]]."]]"""]] + +A *file descriptor* is a [[concept]] of [[UNIX]], and represents a +non-[[persistent|persistency]] handle to an object (a file, for example). With +respect to specific aspects, it is comparable to a [[capability]]. diff --git a/virtualization.mdwn b/virtualization.mdwn index 3a207ae8..78457eb9 100644 --- a/virtualization.mdwn +++ b/virtualization.mdwn @@ -6,8 +6,11 @@ id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + + * [[hurd/virtualization]] in the GNU Hurd's context. + # External -- cgit v1.2.3