diff options
| -rw-r--r-- | Mach/MachConcepts.mdwn | 4 |
1 files changed, 3 insertions, 1 deletions
diff --git a/Mach/MachConcepts.mdwn b/Mach/MachConcepts.mdwn index 61e84b09..8544c35d 100644 --- a/Mach/MachConcepts.mdwn +++ b/Mach/MachConcepts.mdwn @@ -12,7 +12,7 @@ A GNU Mach system consists of many <dfn>tasks</dfn>. You can think Mach tasks as As an example `mmap` POSIX interface (it maps file content to a memory region thus "loading" a file in no time) can be implemented by assigning a special memory manager to a memory range. When a thread accesses a page in that region our custom memory manager can load the corresponding block of the file. <dfn>Wired pages</dfn> are those that cannot be paged out. For example Mach itself is a task with its address space and threads and all of its pages are wired. <dfn>Precious pages</dfn> are those that must not be discarded silently when they are not modified and memory is needed. For example a memory manager that shares memory across a network could not restore a page if it is silently discarded because it is unmodified. This is not valid for the well-known pager managers that use disks as backing store. -* **<dfn>Communication channels</dfn>** in Mach are called <dfn>ports</dfn>. They can be compared with \*nix system calls but have **much** richer semantics and are ubiquitous in a Mach environment. +* **<dfn>Communication channels</dfn>** in Mach are called <dfn>ports</dfn>. They can be compared with \*nix system calls but have **much** richer semantics and are ubiquitous in a Mach environment. In the Hurd ports are used as <dfn>object references</dfn>. Hurd programs use these object references only by calling <dfn>methods</dfn> defined in interface files (`.defs` files). Ports themselves are queues of <dfn>messages</dfn>. There can be multiple senders and only one receiver of these messages -- ports are unidirectional communication channels. To send or receive a message a task must have corresponding <dfn>port right</dfn> to the port. (Of course a task can't execute code, it is the threads within it that do that.) Mach knows what port rights belong to each task but threads in tasks refer to ports by <dfn>port names</dfn>. They are integer numbers that form the <dfn>port name space</dfn> of a task. Ports are automatically destroyed when there is no associated port right to them. So the picture is that after obtaining a <dfn>port send right</dfn>, the client uses a port name to send messages to the port. They are (probably) queued and when the server task tries to receive messages using its <dfn>port receive right</dfn> it gets the message(s). Messages are not only opaque data. They can contain port rights to be passed to another task. Port rights are copied or moved. Notice that port receive right must be moved but not copied because there can't be more than one task that hold receive right to a port. The receiving task creates a new port name to the port right received. @@ -24,6 +24,8 @@ A GNU Mach system consists of many <dfn>tasks</dfn>. You can think Mach tasks as **Controlling tasks, their address space, threads and other system objects** in Mach is implemented by using ports. Almost all of the Mach API (creating threads, etc) is implemented by sending messages to ports. **Device drivers** that reside in kernel space are controlled by ports too. In GNU Mach 1.2 these drivers are the Linux 2.0.36 ones. [[OskitMach]] provides more recent drivers. Ports abstraction allows RPCs to be executed on another computer transparently. This can be implemented with user task but there is an implementation in the kernel (called <dfn>NORMA</dfn>, not tested in GNU Mach) that do that. +More detailed information about GNU Mach interfaces can be found in [The GNU Mach Reference Manual](http://www.gnu.org/software/hurd/gnumach-doc/mach.html). + -- [[Main/OgnyanKulev]] - 09 Dec 2002 Here is a link to some Mach 3 (pre GNU) documents that might be of help circa 1992. |