From 9cedf47ebaebf9224fbbb9670001567098943d79 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 14 Sep 2007 16:35:32 +0200 Subject: Rename some pages to be more consistent. --- abac.mdwn | 2 +- capabilities.mdwn | 40 ------ capability.mdwn | 40 ++++++ confused_deputy.mdwn | 21 +++ confuseddeputy.mdwn | 21 --- hurd/authentication.mdwn | 4 +- ipc.mdwn | 2 +- microkernel/mach/concepts.mdwn | 11 +- microkernel/mach/external_pager_mechanism.mdwn | 188 +++++++++++++++++++++++++ microkernel/mach/externalpagermechanism.mdwn | 188 ------------------------- microkernel/mach/port.mdwn | 10 +- naming_context.mdwn | 31 ++++ namingcontext.mdwn | 31 ---- persistency.mdwn | 25 ++++ persistent.mdwn | 25 ---- 15 files changed, 319 insertions(+), 320 deletions(-) delete mode 100644 capabilities.mdwn create mode 100644 capability.mdwn create mode 100644 confused_deputy.mdwn delete mode 100644 confuseddeputy.mdwn create mode 100644 microkernel/mach/external_pager_mechanism.mdwn delete mode 100644 microkernel/mach/externalpagermechanism.mdwn create mode 100644 naming_context.mdwn delete mode 100644 namingcontext.mdwn create mode 100644 persistency.mdwn delete mode 100644 persistent.mdwn diff --git a/abac.mdwn b/abac.mdwn index d51c85dd..c71ea00a 100644 --- a/abac.mdwn +++ b/abac.mdwn @@ -20,6 +20,6 @@ In this model, access is not granted based on the identity of the caller but by an authorizing agent that delegates access to a particular resource. Such authorization is then encapsulated in -[[capabilities]] allowing them to be freely [[delegated]]. +[[capabilities|capability]] allowing them to be freely [[delegated|delegation]]. See also [[IBAC]]. diff --git a/capabilities.mdwn b/capabilities.mdwn deleted file mode 100644 index a483c0e7..00000000 --- a/capabilities.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -[[license text=""" -Copyright © 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -A capability is a protected reference. It is a reference in that -it designates an object; it is protected in that in cannot be -forged. A capabilities both designates the object it refers to and -carries the authority to manipulate it. - -By binding [[designation]] and [[authorization]] together, capabilities -simplify [[delegation]]. Imagine that program instance A wants to -tell program B to use a particular file to store some data. -Further imagine that A and B are running in different [[TrustDomains]] -(e.g., with different UIDs). If A sends B just the name -of the file, B needs to first ensure that he does not accidentally -enable A to access the file on his own authority. That is, B wants -to protect against A hijacking his authority. (This problem is -refused to the [[ConfusedDeputy]] problem.) Also, since A likely -sent a string to identify the file to B, the identifier lacks a -[[NamingContext]] and therefore may resolve to a different object -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]]. To work around this, [[ACL]]s are used to -recover authority. diff --git a/capability.mdwn b/capability.mdwn new file mode 100644 index 00000000..06d3cf4a --- /dev/null +++ b/capability.mdwn @@ -0,0 +1,40 @@ +[[license text=""" +Copyright © 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +A capability is a protected reference. It is a reference in that +it designates an object; it is protected in that in cannot be +forged. A capabilities both designates the object it refers to and +carries the authority to manipulate it. + +By binding [[designation]] and [[authorization]] together, capabilities +simplify [[delegation]]. Imagine that program instance A wants to +tell program B to use a particular file to store some data. +Further imagine that A and B are running in different [[trust_domains]] +(e.g., with different UIDs). If A sends B just the name +of the file, B needs to first ensure that he does not accidentally +enable A to access the file on his own authority. That is, B wants +to protect against A hijacking his authority. (This problem is +refused to the [[confused_deputy]] problem.) Also, since A likely +sent a string to identify the file to B, the identifier lacks a +[[naming_context]] and therefore may resolve to a different object +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. diff --git a/confused_deputy.mdwn b/confused_deputy.mdwn new file mode 100644 index 00000000..1f03194b --- /dev/null +++ b/confused_deputy.mdwn @@ -0,0 +1,21 @@ +[[license text=""" +Copyright © 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +[The confused deputy](http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html) +problem was articulated by Norm Hardy. It is a possible consequence +when [[designation]] and [[authorization]] are separated. [[Capabilities|capability]] +help with this problem. diff --git a/confuseddeputy.mdwn b/confuseddeputy.mdwn deleted file mode 100644 index 07df292b..00000000 --- a/confuseddeputy.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[license text=""" -Copyright © 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -[The confused deputy](http://www.cis.upenn.edu/~KeyKOS/ConfusedDeputy.html) -problem was articulated by Norm Hardy. It is a possible consequence -when [[designation]] and [[authorization]] are separated. [[Capabilities]] -help with this problem. diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index 4170c818..7ccd9b45 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -16,9 +16,9 @@ redistribute your contributions. """]] UIDs on the Hurd are separate from processes. A process has -[[capabilities]] designating so-called UID vectors that +[[capabilities|capability]] designating so-called UID vectors that are implemented by an [[auth]] server. This -makes them easily [[virtualizable]]. +makes them easily [[virtualizable|virtualization]]. When a process wishes to gain access to a resource provided by a third party (e.g., a file system) and that party wishes to authenticate the client diff --git a/ipc.mdwn b/ipc.mdwn index 78d74f33..2b6b19d8 100644 --- a/ipc.mdwn +++ b/ipc.mdwn @@ -32,5 +32,5 @@ any [[destructive_interference]] thereby removing the need for the caller to [[trust]] the callee thus reducing the former's [[tcb]]. When done systematically, this can increase the system's [[robustness]]. To this end, microkernels provide richer IPC semantics that include -the ability to transfer [[capabilities]] and to use [[virtual_memory]] +the ability to transfer [[capabilities|capability]] and to use [[virtual_memory]] [[mechanism]]s to copy data. diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn index f81e4e4f..04dbb1c6 100644 --- a/microkernel/mach/concepts.mdwn +++ b/microkernel/mach/concepts.mdwn @@ -1,7 +1,6 @@ -[[Mach]] is a first-generation [[microkernel]]. Mach's basic abstractions include -[[AddressSpace]]s in the form of [[Mach/Task]]s, execution contexts in the -form of threads, [[Mach/IPC]], [[capabilities]] in the form of -[[Mach/Ports]], and [[Mach/MemoryObjects]], which enable -Mach's [[Mach/ExternalPagerMechanism]]. +[[Mach]] is a first-generation [[microkernel]]. Mach's basic abstractions +include [[address_space]]s in the form of [[task]]s, execution contexts in the +form of [[thread]]s, [[IPC]], [[capabilities|capability]] in the form of [[port]]s, and +[[memory_object]]s, which enable Mach's [[external_pager_mechanism]]. -Mach's API is well-[[documented|Mach/Documentation]]. \ No newline at end of file +Mach's [[API]] is well-[[documented|documentation]]. diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn new file mode 100644 index 00000000..169745fb --- /dev/null +++ b/microkernel/mach/external_pager_mechanism.mdwn @@ -0,0 +1,188 @@ +[[license text=""" +Copyright © 2002, 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +Mach provides a so-called external pager [[mechanism]]. This +mechanism serves to separate *managing memory* from *managing +content*. Mach does the former while user space tasks do the +latter. + + +# Introduction + +In Mach, a task's [[Mach/AddressSpace]] consists of references +to [[Mach/MemoryObjects]]. A memory object is designated using +a [[port]] (a port is just a [[capability]]) and +implemented by a normal process. + +To associate a memory object with a portion of a task's +address space, vm\_map is invoked a capability designating +the task and passing a reference to the memory object +and the offset at which to install it. (The first time +a task maps an object, Mach sends an initialization message +to the server including a control capability, which it uses +to supply pages to the kernel.) This is essentially +the same as mapping a file into an address space on Unix +using mmap. + +When a task faults, Mach checks to see if there is a memory +object associated with the fault address. If not, the task +is sent an exception, which is normally further propagated +as a segmentation fault. If there is an associated memory +object, Mach checks whether the corresponding page is in core. +If it is, it installs the page and resumes the task. Mach +then invokes the memory object with the memory\_object\_request +method and the page to read. The memory manager then fetches +or creates the content as appropriate and supplies it to +Mach using the memory\_object\_supply method. + + +# Creating and Mapping a Memory Object + +The following illustrates the basic idea: + +> ________ +> / \ +> | Mach | +> \________/ +> /| / |\ \ +> (C) vm_map / / m_o_ready (E)\ \ (D) memory_object_init +> / |/ (F) return \ \| +> ________ ________ +> / \ -----> / \ +> | Client | (A) open | Server | +> \________/ <----- \________/ +> (B) memory_object + +(A) The client sends an "open" rpc to the server. + +(B) The server creates a memory object (i.e., a port receive right), adds +it to the port set that it is listening on and returns a capability (a port +send right) to the client. + +(C) The client attempts to map the object into its address space using +the vm\_map rpc. It passes a reference to the port that the server gave +it to the vm server (typically Mach). + +(D) Since Mach has never seen the object before, it queues a +memory\_object\_init on the given port along with a send right (the +memory control port) for the manager to use to send messages to the +kernel and also as an authentication mechanism for future +interactions: the port is supplied so that the manager will be able to +identify from which kernel a given memory\_object\_* IPC is from. + +(E) The server dequeues the message, initializes internal data +structures to manage the mapping and then invokes the +memory\_object\_ready method on the control object. + +(F) The kernel sees that the manager is ready, sets up the appropriate +mappings in the client and then replies to the vm\_map rpc indicating +success. + +There is nothing stopping others from playing "the kernel." This is +not a security problem: clients must [[trust]] the server from whom they +obtain memory objects and also the servers with whom they share +the object. Multiple memory managers are a reality that should be +dealt with gracefully: they are useful for network transparent +mappings etc. + + +# Resolving Page Faults + +> (G) Client ________ +> resumed / \ +> | Mach | +> (A) Fault +----|------+ | \ (B) m_o_request (C) store_read +> ____|___ \_____|__/ |\ \| ________ _________ +> / +---\-------+ \ / \ / \ +> | Client | (F) | Server |<===>| storeio | +> \________/ m_o_supply \________/ \_________/ +> (E) return data | ^ +> | | (D) device_read +> v | +> ________ +> / Device \ +> | Driver | +> \________/ +> | ^ +> | | +> v +> ____________ +> / Hardware \ + +(A) The client does a memory access and faults. The kernel catches +the fault and maps the address to the appropriate memory object. It +then invokes the memory\_object\_request method on the associated +capability. (In addition to the page to supply, it also supplies the +control port so that the server can determine which kernel +sent the message.) + +(B) The manager dequeues the message. On the Hurd, this is translated +into a store\_read: a function in the libstore library which is used to +transparently manage block devices. The storeio server starts off as +a separate process, however, if the server has the appropriate +permission, the backing object can be contacted directly by the +server. This layer of indirection is desirable when, for instance, a +storeio running as root may want to only permit read only access to a +resource, yet it cannot safely transfer its handle to the client. In +this case, it would proxy the requests. + +(C) The storeio server contacts, for instance, a device driver to do +the read. This could also be a network block device (the NBD server +in GNU/Linux), a file, a memory object, etc. + +(D) The device driver allocates an anonymous page from the default +pager and reads the data into it. Once all of the operations are +complete, the device returns the data to the client unmapping it from +its own address space at the same time. + +(E) The storeio transfers the page to the server. The page is still +anonymous. + +(F) The manager does a memory\_object\_supply transferring the page to +the kernel. Only now is the page not considered to be anonymous but +managed. + +(G) The kernel caches the page, installs it in the client's virtual +address space and finally, resumes the client. + + +# Paging Data Out + +> Change manager Pager m_o_return store_write +> \ _________ (B) __(A)__ (C) ________ (D) _______ +> S | / Default \ / \ / \ / \ +> W |<=>| Pager |<=>| Mach |==>| server |<=>| storeio |<=> +> A | \_________/ \________/ \________/ \_______/ +> P | +> / + +(A) The paging [[policy]] is implemented by Mach: servers just implement +the [[mechanism]]. + +(B) Once the kernel has selected a page that it would like to evict, it +changes the manager from the server to the default pager. This way, +if the server does not deallocate the page quickly enough, it cannot +cause a denial of service: the kernel will just later double page it +to swap (the default pager is part of the [[tcb]]). + +(C) Mach then invokes memory\_object\_return method on the control +object. The server is expected to save the page free it in a timely +fashion. The server is not required to send a response to the kernel. + +(D) The manager then transfers the data to the storeio which +eventually sends it to disk. The device driver consumes the memory +doing the equivalent of a vm\_deallocate. diff --git a/microkernel/mach/externalpagermechanism.mdwn b/microkernel/mach/externalpagermechanism.mdwn deleted file mode 100644 index 169745fb..00000000 --- a/microkernel/mach/externalpagermechanism.mdwn +++ /dev/null @@ -1,188 +0,0 @@ -[[license text=""" -Copyright © 2002, 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -Mach provides a so-called external pager [[mechanism]]. This -mechanism serves to separate *managing memory* from *managing -content*. Mach does the former while user space tasks do the -latter. - - -# Introduction - -In Mach, a task's [[Mach/AddressSpace]] consists of references -to [[Mach/MemoryObjects]]. A memory object is designated using -a [[port]] (a port is just a [[capability]]) and -implemented by a normal process. - -To associate a memory object with a portion of a task's -address space, vm\_map is invoked a capability designating -the task and passing a reference to the memory object -and the offset at which to install it. (The first time -a task maps an object, Mach sends an initialization message -to the server including a control capability, which it uses -to supply pages to the kernel.) This is essentially -the same as mapping a file into an address space on Unix -using mmap. - -When a task faults, Mach checks to see if there is a memory -object associated with the fault address. If not, the task -is sent an exception, which is normally further propagated -as a segmentation fault. If there is an associated memory -object, Mach checks whether the corresponding page is in core. -If it is, it installs the page and resumes the task. Mach -then invokes the memory object with the memory\_object\_request -method and the page to read. The memory manager then fetches -or creates the content as appropriate and supplies it to -Mach using the memory\_object\_supply method. - - -# Creating and Mapping a Memory Object - -The following illustrates the basic idea: - -> ________ -> / \ -> | Mach | -> \________/ -> /| / |\ \ -> (C) vm_map / / m_o_ready (E)\ \ (D) memory_object_init -> / |/ (F) return \ \| -> ________ ________ -> / \ -----> / \ -> | Client | (A) open | Server | -> \________/ <----- \________/ -> (B) memory_object - -(A) The client sends an "open" rpc to the server. - -(B) The server creates a memory object (i.e., a port receive right), adds -it to the port set that it is listening on and returns a capability (a port -send right) to the client. - -(C) The client attempts to map the object into its address space using -the vm\_map rpc. It passes a reference to the port that the server gave -it to the vm server (typically Mach). - -(D) Since Mach has never seen the object before, it queues a -memory\_object\_init on the given port along with a send right (the -memory control port) for the manager to use to send messages to the -kernel and also as an authentication mechanism for future -interactions: the port is supplied so that the manager will be able to -identify from which kernel a given memory\_object\_* IPC is from. - -(E) The server dequeues the message, initializes internal data -structures to manage the mapping and then invokes the -memory\_object\_ready method on the control object. - -(F) The kernel sees that the manager is ready, sets up the appropriate -mappings in the client and then replies to the vm\_map rpc indicating -success. - -There is nothing stopping others from playing "the kernel." This is -not a security problem: clients must [[trust]] the server from whom they -obtain memory objects and also the servers with whom they share -the object. Multiple memory managers are a reality that should be -dealt with gracefully: they are useful for network transparent -mappings etc. - - -# Resolving Page Faults - -> (G) Client ________ -> resumed / \ -> | Mach | -> (A) Fault +----|------+ | \ (B) m_o_request (C) store_read -> ____|___ \_____|__/ |\ \| ________ _________ -> / +---\-------+ \ / \ / \ -> | Client | (F) | Server |<===>| storeio | -> \________/ m_o_supply \________/ \_________/ -> (E) return data | ^ -> | | (D) device_read -> v | -> ________ -> / Device \ -> | Driver | -> \________/ -> | ^ -> | | -> v -> ____________ -> / Hardware \ - -(A) The client does a memory access and faults. The kernel catches -the fault and maps the address to the appropriate memory object. It -then invokes the memory\_object\_request method on the associated -capability. (In addition to the page to supply, it also supplies the -control port so that the server can determine which kernel -sent the message.) - -(B) The manager dequeues the message. On the Hurd, this is translated -into a store\_read: a function in the libstore library which is used to -transparently manage block devices. The storeio server starts off as -a separate process, however, if the server has the appropriate -permission, the backing object can be contacted directly by the -server. This layer of indirection is desirable when, for instance, a -storeio running as root may want to only permit read only access to a -resource, yet it cannot safely transfer its handle to the client. In -this case, it would proxy the requests. - -(C) The storeio server contacts, for instance, a device driver to do -the read. This could also be a network block device (the NBD server -in GNU/Linux), a file, a memory object, etc. - -(D) The device driver allocates an anonymous page from the default -pager and reads the data into it. Once all of the operations are -complete, the device returns the data to the client unmapping it from -its own address space at the same time. - -(E) The storeio transfers the page to the server. The page is still -anonymous. - -(F) The manager does a memory\_object\_supply transferring the page to -the kernel. Only now is the page not considered to be anonymous but -managed. - -(G) The kernel caches the page, installs it in the client's virtual -address space and finally, resumes the client. - - -# Paging Data Out - -> Change manager Pager m_o_return store_write -> \ _________ (B) __(A)__ (C) ________ (D) _______ -> S | / Default \ / \ / \ / \ -> W |<=>| Pager |<=>| Mach |==>| server |<=>| storeio |<=> -> A | \_________/ \________/ \________/ \_______/ -> P | -> / - -(A) The paging [[policy]] is implemented by Mach: servers just implement -the [[mechanism]]. - -(B) Once the kernel has selected a page that it would like to evict, it -changes the manager from the server to the default pager. This way, -if the server does not deallocate the page quickly enough, it cannot -cause a denial of service: the kernel will just later double page it -to swap (the default pager is part of the [[tcb]]). - -(C) Mach then invokes memory\_object\_return method on the control -object. The server is expected to save the page free it in a timely -fashion. The server is not required to send a response to the kernel. - -(D) The manager then transfers the data to the storeio which -eventually sends it to disk. The device driver consumes the memory -doing the equivalent of a vm\_deallocate. diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index 47ef427a..5dcc9ba3 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -15,7 +15,7 @@ your rights under copyright, including the rights to copy, modify, and redistribute your contributions. """]] -Mach ports are [[capabilities]]. +Mach ports are [[capabilities|capability]]. A Mach port is a kernel queue. Each port has associated with it a receive right and one or more send and send-once rights. @@ -33,15 +33,15 @@ a single message). Enqueuing a message is equivalent to [[invoke|invoking]] a capability. Send and receive rights are named using local names. Each -task has associated with it a port address space. A ports +task has associated with it a port [[address_space]]. A ports are addressed via this table. Each task thus has its own -private [[NamingContext]] for ports. +private [[naming_context]] for ports. -Ports can be [[delegate]]d in an IPC message. When the +Ports can be [[delegate]]d in an [[IPC]] message. When the receiver dequeues the message, the right is made available to it. -A thread can only block receiving on a single port. To work +A [[thread]] can only block receiving on a single port. To work around this, the concept of a port set was introduced. A receive right can be added to (at most) one port set. When a thread receives from a port set, it dequeues from any of the ports that diff --git a/naming_context.mdwn b/naming_context.mdwn new file mode 100644 index 00000000..be041211 --- /dev/null +++ b/naming_context.mdwn @@ -0,0 +1,31 @@ +[[license text=""" +Copyright © 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +Names are bindings to objects, however, to find an object +given a name, the relation must be looked up in a +naming context. A problem with using string as names is +that it is very easy to lose track of the correct naming +context. This is one of the problem with [[PassiveTranslators]]: +a passive translator is a string. When the node is accessed +on which the passive translator is set and there is no active +translator, then an active translator is started using the +passive translator setting. The active translator is started +by the file system, not the program instance that set the +passive translator. The passive translator settings are +therefore resolved in the file system's naming context, which +may be different from that of the program instance that set the +passive translator setting. diff --git a/namingcontext.mdwn b/namingcontext.mdwn deleted file mode 100644 index be041211..00000000 --- a/namingcontext.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[license text=""" -Copyright © 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -Names are bindings to objects, however, to find an object -given a name, the relation must be looked up in a -naming context. A problem with using string as names is -that it is very easy to lose track of the correct naming -context. This is one of the problem with [[PassiveTranslators]]: -a passive translator is a string. When the node is accessed -on which the passive translator is set and there is no active -translator, then an active translator is started using the -passive translator setting. The active translator is started -by the file system, not the program instance that set the -passive translator. The passive translator settings are -therefore resolved in the file system's naming context, which -may be different from that of the program instance that set the -passive translator setting. diff --git a/persistency.mdwn b/persistency.mdwn new file mode 100644 index 00000000..e9d0a248 --- /dev/null +++ b/persistency.mdwn @@ -0,0 +1,25 @@ +[[license text=""" +Copyright © 2007 Free Software Foundation, Inc. + +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.txt]]. + +By contributing to this page, you agree to assign copyright for your +contribution to the Free Software Foundation. The Free Software Foundation +promises to always use either a verbatim copying license or a free +documentation license when publishing your contribution. We grant you back all +your rights under copyright, including the rights to copy, modify, and +redistribute your contributions. +"""]] + +A persistent object is an object that survives reboot. +On Unix, files and directories are persistent but +processes and file descriptors are not. EROS is +an example of an orthogonally persistent system: +processes and capabilities 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/persistent.mdwn b/persistent.mdwn deleted file mode 100644 index e9d0a248..00000000 --- a/persistent.mdwn +++ /dev/null @@ -1,25 +0,0 @@ -[[license text=""" -Copyright © 2007 Free Software Foundation, Inc. - -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.txt]]. - -By contributing to this page, you agree to assign copyright for your -contribution to the Free Software Foundation. The Free Software Foundation -promises to always use either a verbatim copying license or a free -documentation license when publishing your contribution. We grant you back all -your rights under copyright, including the rights to copy, modify, and -redistribute your contributions. -"""]] - -A persistent object is an object that survives reboot. -On Unix, files and directories are persistent but -processes and file descriptors are not. EROS is -an example of an orthogonally persistent system: -processes and capabilities 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. -- cgit v1.2.3