Merge branch 'master' of flubber:~wiki/wiki

11 files changed, 311 insertions, 128 deletions

diff --git a/Mach/GNUMach.mdwn b/Mach/GNUMach.mdwn
index f0134a8d..a7f47ac9 100644
--- a/Mach/GNUMach.mdwn
+++ b/Mach/GNUMach.mdwn
@@ -1,48 +1,13 @@
-# <a name="Table_of_Contents"> Table of Contents </a>
+GNU Mach runs on x86 machines (it does not support 64-bit machines).  GNU
+Mach is currently used by the GNU [[Hurd]].
 
-%TOC%
+GNU Mach remains compatible with Mach 3.0.
 
-# <a name="Introduction_to_GNU_Mach"> </a> Introduction to GNU Mach
+The majority of GNU Mach's device drivers are from Linux 2.0.  They were
+added using glue code, i.e., a Linux emulation layer in Mach.
 
-GNU Mach is the microkernel of the GNU system. A microkernel provides only a limited functionality, just enough abstraction on top of the hardware to run the rest of the operating system in user space. The GNU Hurd servers and the GNU C library implement the POSIX compatible base of the GNU system on top of the microkernel architecture provided by Mach.
+# Related Links
 
-Currently, GNU Mach runs on IA32 machines. GNU Mach should, and probably will, be ported to other hardware architectures in the future. Mach was ported to many operating systems in the past.
-
-GNU Mach is maintained by the Hurd developers for the GNU project. If you need help with GNU Mach or want to contribute to the development of the microkernel, you should [contact the Hurd people](http://www.gnu.org/software/hurd/help.html).
-
-For another view, please see the [Wikipedia Mach kernel entry](http://www.wikipedia.com/wiki/Mach+kernel) -- [[Main/GrantBow]] - 02 Jun 2002
-
-# <a name="Advantages_of_GNU_Mach"> </a> Advantages of GNU Mach
-
-GNU Mach is not the most advanced microkernel known to the planet, nor is it the fastest or smallest, but it has a rich set of interfaces and some features which make it useful as the base of the Hurd system.
-
-<dl>
-  <dt><b>it's free software</b></dt>
-  <dd> Anybody can use, modify, and redistribute it under the terms of the <a href="http://www.gnu.org/copyleft/gpl.html" target="_top">GNU General Public License (GPL)</a>.it's built to survive As a microkernel, GNU Mach doesn't implement a lot of the features commonly found in an operating system, but only the bare minimum that is required to implement a full operating system on top of it. This means that a lot of the operating system code is maintained outside of GNU Mach, and while this code may go through a complete redesign, the code of the microkernel can remain comparatively stable. </dd>
-  <dt><b>it's scalable</b></dt>
-  <dd> Mach is particularly well suited for SMP and network cluster techniques. Thread support is provided at the kernel level, and the kernel itself takes advantage of that. Network transparency at the IPC level makes resources of the system available across machine boundaries (with NORMA IPC, currently not available in GNU Mach). </dd>
-  <dt><b>it exists</b></dt>
-  <dd> The Mach microkernel is real software that works Right Now. It is not a research or a proposal. You don't have to wait at all before you can start using and developing it. Mach has been used in many operating systems in the past, usually as the base for a single UNIX server. In the GNU system, Mach is the base of a functional multi-server operating system, the Hurd. </dd>
-</dl>
-
-# <a name="Status_of_the_project"> Status of the project </a>
-
-GNU Mach is used as the default microkernel in the GNU/Hurd system. It is compatible with other popular Mach distributions. The device drivers for block devices and network cards are taken from Linux 2.0.x kernel versions, and so a broad range of common hardware is supported.
-
-However, the Linux device drivers have been improved greatly since the 2.0.x version, and a new version of Mach based on the OSKit library is being worked on, which uses newer drivers and in general has cleaner machine specific support code.
-
-----
-
-Copyright (C) 2001, 2002 Free Software Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA 02111, USA
-
-Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
-
--- [[Main/JoachimNilsson]] - 13 May 2002
-
-A unique advantage is being able to run a [Neighbor Hurd](http://www.gnu.org/software/hurd/howto/subhurd.html).
-
--- [[Main/GrantBow]] - 28 Sep 2002
-
-I don't want to refactor this content as it's a Verbatim copy. However I want to add that GNUMach 1.3 uses Linux drivers as of the Linux kernel version 2.0.36.
-
--- [[Main/GrantBow]] - 09 Oct 2002
+* [[BuildingGNUMach]]
+* [[GNUMachRevivalProject]] - GNU Mach Projects
+* [[Ports]] - Ports to other Architectures
\ No newline at end of file
diff --git a/Mach/GNUMach/ports.mdwn b/Mach/GNUMach/ports.mdwn
new file mode 100644
index 00000000..f6e98d5a
--- /dev/null
+++ b/Mach/GNUMach/ports.mdwn
@@ -0,0 +1,2 @@
+* [PowerPC](http://www.pjbruin.dds.nl/hurd/)
+
diff --git a/Mach/MachConcepts.mdwn b/Mach/MachConcepts.mdwn
index b691a119..f81e4e4f 100644
--- a/Mach/MachConcepts.mdwn
+++ b/Mach/MachConcepts.mdwn
@@ -1,67 +1,7 @@
-## <a name="Table_Of_Contents"> Table Of Contents </a>
+[[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]].
 
-%TOC%
-
-A GNU Mach system consists of many _tasks_. You can think Mach tasks as \*nix processes but they are not the same. In processes there are signals, process/group/session IDs, file descriptors and many other things. Tasks are used for resource allocation and sharing. They are _resource containers_.
-
-## <a name="Execution_time"> Execution time </a>
-
-Tasks themselves don't spend execution time. The active entities in Mach are called _threads_ (points of execution). Each thread belongs to one and only one task and runs concurrently with all the other threads of a system. Tasks are resource environments (address space and communication channels) for threads.
-
-Using threads is much more cheaper than using \*nix processes. Switching between threads in one task change processor registers' state but switching between threads in different tasks involves context switching (changing resource environment) which is slow on most computer architectures.
-
-In a general case, two threads of one task are able to run on two different _processors_ simultaneously. That's the way Mach is designed. (Note that you can't play with the SMP support in GNU Mach yet.) Mach organizes processors into _processor sets_. A thread can be assigned to a processor set in order to be executed in any of the processors in the processor set. Of course, it is expected that all the processors in a processor set use shared memory. There is an optional and experimental support for building _multicomputers_ build from _nodes_.
-
-Threads have scheduling parameters and contain various statistics about them.
-
-## <a name="Address_space"> Address space </a>
-
-_Address space_ in Mach defines the valid addresses that can be used by threads in the task that owns that address space. Each task has only one address space and each address space belongs to only one task. So when we want to name an address space (e.g. in the Mach API) we name it by the task it belongs to.
-
-Address space is divided into _pages_. Each page has individual properties like _access rights_ (read/write/execute), _inheritance attributes_ (no inheritance/copy/share) and some other system properties discussed later. Page manipulation is optimized to help moving large blocks of data from one address space to another (read: from a thread of task A to a thread of task B; further read: client/server technology).
-
-Memory ranges of pages that can be controlled as a whole are called _memory objects_. The physical memory is conceived as a _memory cache_ that contains _memory cache objects_. So when a thread accesses a page in its task's address space, the memory object that includes this page is cached in the memory cache. Memory objects are paged out and paged in by _memory managers_ that can be user tasks. The decision when they should be paged in or paged out is left to Mach. Each memory object has an ordered list of memory managers that provide paging. The last one tried is the default memory manager that resides in the microkernel. The others are generally user tasks. The default memory manager is needed because the microkernel can't wait infinitely someone else to free the memory cache: it just calls the next memory manager hoping it to succeed.
-
-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.
-
-_Wired pages_ are those that cannot be paged out. For example, Mach itself is a task with its own address space and threads, and all of its pages are wired.
-
-_Precious pages_ are those that must not be discarded silently when they are clean 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.
-
-## <a name="Communication_channels"> Communication channels </a>
-
-_Communication channels_ in Mach are called _ports_. 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 _object references_. Hurd programs use these object references only by calling _methods_ defined in interface files (`.defs` files).
-
-Ports themselves are queues of _messages_. 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 _port right_ 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 _port names_. They are integer numbers that form the _port name space_ of task. Ports are automatically destroyed when there is no associated port right to them.
-
-So, the picture is that after obtaining a _port send right_, 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 _port receive right_ 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.
-
-Some data in the message can be _out-of-line data_. In the message they are references to memory regions which are _virtually copied_. When the message is received in a task these virtual copies become part of the address space of the task. "Virtual copy" means that it is not copied immediately but when it is changed. This is primarily used to send large blocks of data efficiently because it is too expensive to store them in the kernel address space.
-
-The ability to send port rights to other tasks can be used to easily implement remote procedure calls (RPC) with return results and in/out arguments by sending a port right to which the result have to be returned. This is called _reply port_ and it is usually referred by tasks with _send-once port right_. These port rights allow only one message to be send and after that the port right is immediately destroyed.
-
-All these facilites are used by the _Mach Interface Generator (Mig)_ to provide easy RPC for Mach tasks. Procedure definitions are described in `.defs` files using a Mig-specific Interface Definition Languager (IDL). Then they are compiled by Mig to C stubs and skeletons that have to be compiled and linked to client and server programs respectively. After that client programs call remote procedures more or less like any other C function. These functions are implemented in the stubs and encode arguments into message (_marshalling_), wait for result on a newly created reply port, decode return arguments from the reply message (_unmarshalling_) and pass them to the client program. Similar actions are provided in the skeletons that are linked to server programs. Mig allows very precise semantics to be specified about what the arguments are and how to be passed. Unfortunately Mig can generate only C code.
-
-When server task have to listen to a large number of ports using receive rights it can organize them into _port sets_. Port set look like port receive right but cannot be passed to another task and there are additional operations for including and excluding port receive rights. Waiting for a message from a port set waits all ports in the port set and returns exactly one message from randomly selected port that have message(s) in its queue. This is the only use of port sets.
-
-Ports are kernel-protected resources. There is no way for a task to do anything with a port unless it have corresponding port right. Remember that threads do not deal with port rights directly -- they use port names which refer to port right in a task. The delivery of messages is reliable and strictly ordered -- when a thread sends messages 1 and 2 it is guaranteed that the receiving task will catch them in the same order (but there can be intermediate messages send by other threads).
-
-**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.3, 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 _NORMA_, 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.
-
-<http://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/>
-
--- [[Main/GrantBow]] - 16 Dec 2002
-
-Convert from XHTML to [[TWiki/TextFormattingRules]]
-
--- [[Main/OgnyanKulev]] - 16 Jun 2003
+Mach's API is well-[[documented|Mach/Documentation]].
\ No newline at end of file
diff --git a/Mach/MicroKernelFUD.mdwn b/Mach/MicroKernelFUD.mdwn
index 1961f6d2..0ee5035c 100644
--- a/Mach/MicroKernelFUD.mdwn
+++ b/Mach/MicroKernelFUD.mdwn
@@ -1,8 +1,8 @@
 # <a name="The_Microkernel_Experiment_is_Go"> The Microkernel Experiment is Going On </a>
 
-by [Wolfgang J�hrling](mailto:wolfgang AT pro-linux DOT de) and [Jeroen Dekkers](mailto:jeroen AT dekkers DOT cx)
+by [Wolfgang Jährling](mailto:wolfgang AT pro-linux DOT de) and [Jeroen Dekkers](mailto:jeroen AT dekkers DOT cx)
 
-This article is a response to an [earlier article](http://www.linuxjournal.com/print.php?sid=6105) by Miles Nordin in Linux Journal, where he expressed his personal feelings about microkernels and monolithic kernels. We will try to present a different point of view. Of course, we are also biased, as we are both young hackers who try to turn [the GNU Hurd](http://www.gnu.org/software/hurd/) into a software useful for everyday-work; for those who don't know it (yes, we're abusing this article as an advertisement): The Hurd is a collection of Daemons, currently running on top of the Mach microkernel and providing a replacement for the Unix kernel together with the GNU C Library.
+This article is a response to an [earlier article](http://www.linuxjournal.com/node/6105/print) by Miles Nordin in Linux Journal, where he expressed his personal feelings about microkernels and monolithic kernels. We will try to present a different point of view. Of course, we are also biased, as we are both young hackers who try to turn [the GNU Hurd](http://www.gnu.org/software/hurd/) into a software useful for everyday-work; for those who don't know it (yes, we're abusing this article as an advertisement): The Hurd is a collection of Daemons, currently running on top of the Mach microkernel and providing a replacement for the Unix kernel together with the GNU C Library.
 
 Miles Nordin claimed that microkernels are dead already. But this is not completely true. The first generation of microkernels, which were in fact no real microkernels, are dead. But there is a new generation, which uses a radically different strategy than the original (so-called) microkernels. Thus, microkernels are still a research topic, and today they look more promising than ever before. By now, this is just something we claim, but read on, and you'll find out why we do so.
 
@@ -18,7 +18,7 @@ If you are interested in research about the performance of microkernel based sys
 
 ----
 
-Copyright (C) 2002 Wolfgang J�hrling <br /> Copyright (C) 2002 Jeroen Dekkers
+Copyright (C) 2002 Wolfgang Jährling <br /> Copyright (C) 2002 Jeroen Dekkers
 
 Verbatim copying and distribution of this entire article is permitted in any medium, provided this notice is preserved.
 
diff --git a/Mach/MicroKernelsForBeginners.mdwn b/Mach/MicroKernelsForBeginners.mdwn
index a89b5284..1bfab1ed 100644
--- a/Mach/MicroKernelsForBeginners.mdwn
+++ b/Mach/MicroKernelsForBeginners.mdwn
@@ -1,17 +1,22 @@
-Think of this as a Wiki Pos^H^H^H Yellow Sticky Note Note
+# Concepts
 
-This page is linked to from [[Mach]]. I created it for the purpose of creating a 'beginners meta guide to microkernels'.
+A [[microkernel]] implements a minimal number of abstractions
+that facilitate the realization of operating system services.
 
-Essentially, the rationale is as follows. There are many users of this Wiki who understand microkernels. Many users who come here may want to know more about microkernels, having just heard about them. (I heard years ago, but haven't taken a direct interest in the issues related to them.)
+[[MachConcepts]] are documented here.
 
-As a suggestion as to what should go here:
+Read OSF's Kernel Principles.  Find it under the
+[[documentation]] link.
 
-* Good books to read
-* Good websites to visit
-* Any easy to read papers concerning the topic
+# Exercises
 
-...you get the idea.
+Mach's API is documented in OSF's Kernel API book.  Find it
+under the [[documentation]] link.  Skim it to get an idea
+of how the API looks and then try the following exercises:
 
-nb. The above text is intended as a placeholder for actual content, which I cannot supply myself but think should go here. (Rationale is a reverse application of the 'do unto others...', namely I am most likely not the only thinking this and registering the initial suggestion may help as a catalyst to helping others...)
+Send messages using Mach's IPC mechanism
+([detailed description](http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt)).
 
--- [[Main/JohnAllsup]] - 29 Oct 2003
+Implement your own pager.  Write a server that synthesizes
+content on the fly and have a client map the object into its
+address space and print out the file.
\ No newline at end of file
diff --git a/Mach/OskitMach.mdwn b/Mach/OskitMach.mdwn
index 449e8eb8..d1492654 100644
--- a/Mach/OskitMach.mdwn
+++ b/Mach/OskitMach.mdwn
@@ -1,6 +1,11 @@
-## <a name="Table_of_Contents"> Table of Contents </a>
+[[toc ]]
+
+* [[OskitMachStatusList]]: Status and TODO list (<a href="http://packages.debian.org/gnumach" target="_top">deb status</a>) </li>
+* [[OskitMachPatches]]: Bleeding edge patches </li>
+* [[OskitPatches]]: Useful patches for the OSKit </li>
+* [[BuildingOskitMach]]: How to build your own GNUmach kernel </li>
+* [[RemoteDebugOskitMach]]: How to use gdb to remote debug the GNUmach kernel </li>
 
-%TOC%
 
 ## <a name="About"> About </a>
 
@@ -51,6 +56,3 @@ We have bugs, just like any other software product. To get around the more nasty
 
 See Igor Khavkine's, [i\_khavki@alcor.concordiaNOSPAM.ca](mailto:i_khavki@alcor.concordiaNOSPAM.ca), excellent help to [remote debug oskit-mach over a serial line](http://www.etherhogz.org/doc/oskit-boot.txt), or the local [[RemoteDebugOskitMach]].
 
-----
-
-**_Comments:_**
diff --git a/Mach/hardwarecompatibilitylist.mdwn b/Mach/hardwarecompatibilitylist.mdwn
new file mode 100644
index 00000000..2af15db3
--- /dev/null
+++ b/Mach/hardwarecompatibilitylist.mdwn
@@ -0,0 +1,232 @@
+# CPU Architecture
+
+GNU Mach current only supports the x86 architecture.
+
+# Memory
+
+GNU Mach supports a maximum of 1GB of memory.  If your system has
+more, add the following to the start of your Grub stanza to boot
+the Hurd:
+
+    uppermem 1232896
+
+# Video Cards
+
+Debian distributes a version of Xorg.  If your video card driver
+depends on a special kernel interface such as that provided by
+the agpgart kernel module for the Linux kernel, then your video
+card will only be supported by the Vesa driver.
+
+# Sound
+
+No sound cards are supported at this time.
+
+# USB
+
+USB is not support at this time.
+
+# Storage
+
+IDE Drives are known to work.  SATA drives work in compatibility mode.
+
+## SCSI
+
+* (53c78xx) Linux device driver for SCSI controller NCR 53C7,8xx; on
+  ix86-at enabled by default
+* (AM53C974) Linux device driver for SCSI controller AM53/79C974
+  (am53c974, am79c974); on ix86-at enabled by default
+* (BusLogic) Linux device driver for SCSI controller BusLogic; on
+  ix86-at enabled by default
+* (flashpoint) SCSI flashpoint
+* (NCR53c406a) Linux device driver for SCSI controller NCR53c406a chip
+* (advansys) Linux device driver for SCSI controller AdvanSys; on
+  ix86-at enabled by default
+* (aha152x) Linux device driver for SCSI controller Adaptec
+  AHA-152x/2825 (aha152x, aha2825); on ix86-at enabled by default
+* (aha1542) Linux device driver for SCSI controller Adaptec AHA-1542;
+  on ix86-at enabled by default
+* (aha1740) Linux device driver for SCSI controller Adaptec AHA-1740;
+  on ix86-at enabled by default
+* (aic7xxx) Linux device driver for SCSI controller Adaptec AIC7xxx;
+  on ix86-at enabled by default
+* (dtc) Linux device driver for SCSI controller DTC3180/3280 (dtc3180,
+  dtc3280); on ix86-at enabled by default
+* (eata) Linux device driver for SCSI controller EATA ISA/EISA/PCI
+  (DPT and generic EATA/DMA-compliant boards); on ix86-at enabled by
+  default
+* (eata_dma) Linux device driver for SCSI controller EATA-DMA (DPT,
+  NEC, AT&T, SNI, AST, Olivetti, Alphatronix)
+* (eata_pio) Linux device driver for SCSI controller EATA-PIO (old DPT
+  PM2001, PM2012A); on ix86-at enabled by default
+* (fdomain) Linux device driver for SCSI controller Future Domain
+  16xx; on ix86-at enabled by default
+* (g_NCR5380) Linux device driver for SCSI controller Generic
+  NCR5380/53c400 (ncr5380, ncr53c400)
+* (gdth) Linux device driver for GDT SCSI Disk Array Controller; on
+  ix86-at enabled by default
+* (in2000) Linux device driver for SCSI controller Always IN 2000; on
+  ix86-at enabled by default
+* (ncr53c8xx) Linux device driver for SCSI controller NCR53C8XX
+  (ncr53c8xx, dc390f, dc390u, dc390w); on ix86-at enabled by default
+* (pas16) Linux device driver for SCSI controller PAS16; on ix86-at
+  enabled by default
+* (qlogicfas) Linux device driver for SCSI controller Qlogic FAS; on
+  ix86-at enabled by default
+* (qlogicisp) Linux device driver for SCSI controller Qlogic ISP; on
+  ix86-at enabled by default
+* (seagate) Linux device driver for SCSI controller Seagate ST02,
+  Future Domain TMC-8xx; on ix86-at enabled by default
+* (t128) Linux device driver for SCSI controller Trantor
+  T128/T128F/T228 (t128, t128f, t228); on ix86-at enabled by default
+* (tmscsim) Linux device driver for SCSI controller Tekram DC-390(T)
+  (dc390, dc390t); on ix86-at enabled by default
+* (u14-34f) Linux device driver for SCSI controller UltraStor 14F/34F;
+  on ix86-at enabled by default
+* (ultrastor) Linux device driver for SCSI controller UltraStor; on
+  ix86-at enabled by default
+* (wd7000) Linux device driver for SCSI controller WD 7000; on ix86-at
+  enabled by default
+
+## Other
+
+* (ppa) Linux device driver for IOMEGA Parallel Port ZIP drive; on
+  ix86-at enabled by default
+
+# NICs
+
+* (3c501) Linux device driver for Ethernet controller 3COM 501 (3c501)
+  / Etherlink I; on ix86-at enabled by default
+* (3c503) Linux device driver for Ethernet controller 3Com 503 (3c503)
+  / Etherlink II; on ix86-at enabled by default
+* (3c505) Linux device driver for Ethernet controller 3Com 505 (3c505,
+  elplus); on ix86-at enabled by default
+* (3c507) Linux device driver for Ethernet controller 3Com 507 (3c507,
+  el16); on ix86-at enabled by default
+* (3c509) Linux device driver for Ethernet controller 3Com 509/579
+  (3c509, 3c579) / Etherlink III; on ix86-at enabled by default
+* (3c59x) Linux device driver for Ethernet controller 3Com 59x/90x
+  (3c59x, 3c590, 3c592, 3c595, 3c597, 3c90x, 3c900, 3c905)
+  "Vortex/Boomerang"; on ix86-at enabled by default
+* (3c515) Linux device driver for Ethernet controller 3Com 515 ISA
+  Fast EtherLink; on ix86-at enabled by default
+* (ac3200) Linux device driver for Ethernet controller Ansel
+  Communications EISA 3200; on ix86-at enabled by default
+* (apricot) Linux device driver for Ethernet controller Apricot XEN-II
+  on board ethernet; on ix86-at enabled by default
+* (at1700) Linux device driver for Ethernet controller AT1700 (Fujitsu
+  86965); on ix86-at enabled by default
+* (atp) Linux device driver for Ethernet controller AT-LAN-TEC/RealTek
+  pocket adaptor
+* (de4x5) Linux device driver for Ethernet controller DE4x5 (de4x5,
+  de425, de434, de435, de450, de500); on ix86-at enabled by default
+* (de600) Linux device driver for Ethernet controller D-Link DE-600;
+  on ix86-at enabled by default
+* (de620) Linux device driver for Ethernet controller D-Link DE-620;
+  on ix86-at enabled by default
+* (depca) Linux device driver for Ethernet controller DEPCA (de100,
+  de101, de200, de201, de202, de210, de422); on ix86-at enabled by
+  default
+* (e2100) Linux device driver for Ethernet controller Cabletron E21xx;
+  on ix86-at enabled by default
+* (eepro) Linux device driver for Ethernet controller EtherExpressPro;
+  on ix86-at enabled by default
+* (eepro100) Linux device driver for Ethernet controller Intel
+  EtherExpressPro PCI 10+/100B/100+; on ix86-at enabled by default
+* (eexpress) Linux device driver for Ethernet controller EtherExpress
+  16; on ix86-at enabled by default
+* (epic100) Linux device driver for Ethernet controller SMC 83c170/175
+  EPIC/100 (epic, epic100) / EtherPower II; on ix86-at enabled by
+  default
+* (eth16i) Linux device driver for Ethernet controller ICL EtherTeam
+  16i/32 (eth16i, eth32); on ix86-at enabled by default
+* (ewrk3) Linux device driver for Ethernet controller EtherWORKS 3
+  (ewrk3, de203, de204, de205); on ix86-at enabled by default
+* (fmv18x) Linux device driver for Ethernet controller
+  FMV-181/182/183/184; on ix86-at enabled by default
+* (hamachi) Linux device driver for Ethernet controller Packet Engines
+  "Hamachi" GNIC-2 Gigabit Ethernet; on ix86-at enabled by default
+* (hp-plus) Linux device driver for Ethernet controller HP PCLAN+
+  (27247B and 27252A); on ix86-at enabled by default
+* (hp) Linux device driver for Ethernet controller HP PCLAN (27245 and
+  other 27xxx series); on ix86-at enabled by default
+* (hp100) Linux device driver for Ethernet controller HP 10/100VG
+  PCLAN (ISA, EISA, PCI) (hp100, hpj2577, hpj2573, hpj2585, hp27248b);
+  on ix86-at enabled by default
+* (intel-gige) Linux device driver for Ethernet controller Intel PCI
+  Gigabit Ethernet; on ix86-at enabled by default
+* (lance) Linux device driver for Ethernet controller AMD LANCE and
+  PCnet (at1500, ne2100); on ix86-at enabled by default
+* (myson803) Linux device driver for Ethernet controller Myson MTD803
+  Ethernet adapter series; on ix86-at enabled by default
+* (natsemi) Linux device driver for Ethernet controller National
+  Semiconductor DP8381x series PCI Ethernet; on ix86-at enabled by
+  default
+* (ne) Linux device driver for Ethernet controller NE2000/NE1000 ISA
+  (ne, ne1000, ne2000); on ix86-at enabled by default and for qemu
+* (ne2k-pci) Linux device driver for Ethernet controller PCI NE2000;
+  on ix86-at enabled by default
+* (ni52) Linux device driver for Ethernet controller NI5210; on
+  ix86-at enabled by default
+* (ni65) Linux device driver for Ethernet controller NI6510; on
+  ix86-at enabled by default
+* (ns820) Linux device driver for Ethernet controller National
+  Semiconductor DP8382x series PCI Ethernet; on ix86-at enabled by
+  default
+* (pcnet32) Linux device driver for Ethernet controller AMD PCI
+  PCnet32 (PCI bus NE2100 cards); on ix86-at enabled by default
+* (rtl8139) Linux device driver for Ethernet controller RealTek
+  8129/8139 (rtl8129, rtl8139) (not 8019/8029!); on ix86-at enabled by
+  default
+* (seeq8005) Linux device driver for Ethernet controller Seeq8005; on
+  ix86-at enabled by default
+* (sk_g16) Linux device driver for Ethernet controller Schneider &
+  Koch G16; on ix86-at enabled by default
+* (smc-ultra) Linux device driver for Ethernet controller SMC Ultra;
+  on ix86-at enabled by default
+* (smc-ultra32) Linux device driver for Ethernet controller SMC
+  Ultra32; on ix86-at enabled by default
+* (starfire) Linux device driver for Ethernet controller Adaptec
+  Starfire network adapter; on ix86-at enabled by default
+* (sundance) Linux device driver for Ethernet controller Sundance
+  ST201 "Alta" PCI Ethernet; on ix86-at enabled by default
+* (tlan) Linux device driver for Ethernet controller TI ThunderLAN; on
+  ix86-at enabled by default
+* (tulip) Linux device driver for Ethernet controller DECchip Tulip
+  (dc21x4x) PCI (elcp, tulip); on ix86-at enabled by default
+* (via-rhine) Linux device driver for Ethernet controller VIA Rhine;
+  on ix86-at enabled by default
+* (wavelan) Linux device driver for Ethernet controller AT&T WaveLAN &
+  DEC RoamAbout DS
+* (wd) Linux device driver for Ethernet controller WD80x3; on ix86-at
+  enabled by default
+* (winbond-840) Linux device driver for Ethernet controller Winbond
+  W89c840 PCI Ethernet; on ix86-at enabled by default
+* (yellowfin) Linux device driver for Ethernet controller Packet
+  Engines Yellowfin Gigabit-NIC; on ix86-at enabled by default
+* (znet) Linux device driver for Ethernet controller Zenith Z-Note
+  (znet, znote); on ix86-at enabled by default
+* (i82365) Linux device driver for Intel 82365 PC Card controller; on
+  ix86-at enabled by default
+
+
+# PCMCIA
+
+* (3c574_cs) Linux device driver for 3Com 3c574 ``RoadRunner'' PCMCIA
+  Ethernet; on ix86-at enabled by default
+* (3c589_cs) Linux device driver for 3Com 3c589 PCMCIA Ethernet card;
+  on ix86-at enabled by default
+* (axnet_cs) Linux device driver for Asix AX88190-based PCMCIA
+  Ethernet adapters; on ix86-at enabled by default
+* (fmvj18x_cs) Linux device driver for fmvj18x chipset based PCMCIA
+  Ethernet cards; on ix86-at enabled by default
+* (nmclan_cs) Linux device driver for New Media Ethernet LAN PCMCIA
+  cards; on ix86-at enabled by default
+* (pcnet_cs) Linux device driver for NS8390-based PCMCIA cards; on
+  ix86-at enabled by default
+* (smc91c92_cs) Linux device driver for SMC91c92-based PCMCIA cards;
+  on ix86-at enabled by default
+* (xirc2ps_cs) Linux device driver for Xircom CreditCard and Realport
+  PCMCIA ethernet; on ix86-at enabled by default
+* (orinoco_cs) Linux device driver for Hermes or Prism 2 PCMCIA
+  **Wireless** adapters (Orinoco); on ix86-at enabled by default
+
diff --git a/Mach/mach/documentation.mdwn b/Mach/mach/documentation.mdwn
new file mode 100644
index 00000000..542ad85f
--- /dev/null
+++ b/Mach/mach/documentation.mdwn
@@ -0,0 +1,2 @@
+- OSF's [Kernel Interface](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps)
+- OSF's [Kernel Principles](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps)
\ No newline at end of file
diff --git a/Mach/mach/ipc.mdwn b/Mach/mach/ipc.mdwn
new file mode 100644
index 00000000..42cfacdf
--- /dev/null
+++ b/Mach/mach/ipc.mdwn
@@ -0,0 +1,3 @@
+An IPC is sent by invoking a [[Mach/Port]].
+
+[The Unofficial GNU Mach IPC beginner's guide](http://www.nongnu.org/hurdextras/ipc_guide/ipc_guide.html)
\ No newline at end of file
diff --git a/Mach/mach/ports.mdwn b/Mach/mach/ports.mdwn
new file mode 100644
index 00000000..54cc12ac
--- /dev/null
+++ b/Mach/mach/ports.mdwn
@@ -0,0 +1,31 @@
+Mach ports are [[capabilities]].
+
+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.
+A queue can hold a number of messages.  Once the queue is full,
+the send blocks until their is space to enqueue the message
+(this is interruptible via a timeout mechanism).
+
+A receive right designates a queue and authorizes the holder to
+dequeue messages from the queue, and to create send and send-once
+rights.
+
+Send and send-once rights designate a queue and authorize the
+hold to enqueue messages (in the case of a send-once right,
+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
+are addressed via this table.  Each task thus has its own
+private [[NamingContext]] for ports.
+
+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
+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
+has a message available.
\ No newline at end of file
diff --git a/Mach/ports.mdwn b/Mach/ports.mdwn
new file mode 100644
index 00000000..5fca2efe
--- /dev/null
+++ b/Mach/ports.mdwn
@@ -0,0 +1 @@
+* [PowerPC](http://www.pjbruin.dds.nl/hurd/)