diff options
| -rw-r--r-- | capability.mdwn | 14 | ||||
| -rw-r--r-- | community/gsoc/project_ideas.mdwn | 2 | ||||
| -rw-r--r-- | glibc.mdwn | 9 | ||||
| -rw-r--r-- | glibc/fallocate.mdwn | 17 | ||||
| -rw-r--r-- | glibc/fork.mdwn | 18 | ||||
| -rw-r--r-- | glibc/signals.mdwn | 32 | ||||
| -rw-r--r-- | hurd/glibc/hurd-specific_api.mdwn | 8 | ||||
| -rw-r--r-- | hurd/ng/trivialconfinementvsconstructorvsfork.mdwn | 24 | ||||
| -rw-r--r-- | hurd/translator/magic.mdwn | 11 | ||||
| -rw-r--r-- | open_issues/code_analysis.mdwn | 12 | ||||
| -rw-r--r-- | open_issues/debugging.mdwn | 16 | ||||
| -rw-r--r-- | open_issues/multithreading.mdwn | 4 | ||||
| -rw-r--r-- | open_issues/nightly_builds_deb_packages.mdwn | 6 | ||||
| -rw-r--r-- | open_issues/secure_file_descriptor_handling.mdwn | 9 | ||||
| -rw-r--r-- | open_issues/unit_testing.mdwn | 9 | ||||
| -rw-r--r-- | open_issues/valgrind.mdwn (renamed from community/gsoc/project_ideas/valgrind.mdwn) | 18 | ||||
| -rw-r--r-- | persistency.mdwn | 11 | ||||
| -rw-r--r-- | unix.mdwn | 48 | ||||
| -rw-r--r-- | unix/file_descriptor.mdwn | 13 | ||||
| -rw-r--r-- | virtualization.mdwn | 7 |
20 files changed, 225 insertions, 63 deletions
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]] @@ -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. <dt><tt><b>openport</b> (io_t port, int flags);</tt></dt> <p> </p> - <dd>Open a file descriptor on a port. FLAGS are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are not changed by this. If successful, this consumes a user reference for PORT (which will be deallocated on close.) See <tt>&lt;hurd/io.defs&gt;</tt> and <tt>&lt;hurd/io.h&gt;</tt>.</dd> + <dd>Open a [[unix/file_descriptor]] on a [[microkernel/mach/port]]. FLAGS + are as for <tt>open</tt>; flags affected by <tt>io_set_openmodes</tt> are + not changed by this. If successful, this consumes a user reference for + PORT (which will be deallocated on close.) See + <tt>&lt;hurd/io.defs&gt;</tt> and + <tt>&lt;hurd/io.h&gt;</tt>. + </dd> <p> </p> <dt><tt>task_t</tt></dt> 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 # <a name="POSIX_Fork"> </a> 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. # <a name="Trivial_Confinement_vs_Construct"> Trivial Confinement vs Constructor </a> 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. * <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/community/gsoc/project_ideas/valgrind.mdwn b/open_issues/valgrind.mdwn index 7d68e82d..2b0624d7 100644 --- a/community/gsoc/project_ideas/valgrind.mdwn +++ b/open_issues/valgrind.mdwn @@ -5,8 +5,8 @@ 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]]."]]"""]] [[!meta title="Porting Valgrind to the Hurd"]] @@ -29,17 +29,17 @@ 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: +[[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, +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. +similar to the `ioctl` call on Linux. Each request thus must be handled individually. -Unlike ioctl(), +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, 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. @@ -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]]<!-- + TODO: split out UNIX permission stuff into unix/file_permissions or + something. -->) + + +[[!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 |