diff options
Diffstat (limited to 'hurd/ng/part2systemstructure.mdwn')
| -rw-r--r-- | hurd/ng/part2systemstructure.mdwn | 15 |
1 files changed, 13 insertions, 2 deletions
diff --git a/hurd/ng/part2systemstructure.mdwn b/hurd/ng/part2systemstructure.mdwn index 4ce8026f..0f94ff2a 100644 --- a/hurd/ng/part2systemstructure.mdwn +++ b/hurd/ng/part2systemstructure.mdwn @@ -38,7 +38,12 @@ It is clear from this description that the child's existance is completely deter ## <a name="Canonical_Process_Destruction"> Canonical Process Destruction </a> -Process destruction can be done either cooperatively, or forcibly. The difference corresponds approximately to the difference between SIGTERM and SIGKILL in Unix. To destroy a process cooperatively, a request message is sent to a special capability implemented by the child process. The child can then begin to tear down the program, and at some time send a request back to the parent process to ask for forced process destruction. +Process destruction can be done either cooperatively, or forcibly. The +difference corresponds approximately to the difference between SIGTERM and +SIGKILL in [[Unix]]. To destroy a process cooperatively, a request message is +sent to a special capability implemented by the child process. The child can +then begin to tear down the program, and at some time send a request back to +the parent process to ask for forced process destruction. Forced process destruction can be done by the parent process without any cooperation by the child process. The parent process simply destroys the primary container of the child (this means that the parent process should retain the primary container capability). @@ -84,7 +89,13 @@ I will now describe some common applications that need to be supported, and how ## <a name="System_Services"> System Services </a> -Unix-style suid applications have been proposed as one application for alternative process construction mechanisms. However, suid applications in Unix are, from the perspective of the parent, not confined, only isolated. Thus, they are readily replaced by a system service that is created by the system software, and that runs as a sibling to any user process. Only the ability to invoke the system service needs to be given to the user, not the ability to instantiate it. +[[Unix]]-style suid applications have been proposed as one application for +alternative process construction mechanisms. However, suid applications in +Unix are, from the perspective of the parent, not confined, only isolated. +Thus, they are readily replaced by a system service that is created by the +system software, and that runs as a sibling to any user process. Only the +ability to invoke the system service needs to be given to the user, not the +ability to instantiate it. In fact, no gain can derived from letting the user instantiate system services. In Unix, system services run on durable resources, which the user can not revoke. Thus, the system service needs to acquire its resources from a container that is not derived from the user's primary container. |