diff options
Diffstat (limited to 'microkernel')
22 files changed, 849 insertions, 0 deletions
diff --git a/microkernel/for_beginners.mdwn b/microkernel/for_beginners.mdwn new file mode 100644 index 00000000..24daf290 --- /dev/null +++ b/microkernel/for_beginners.mdwn @@ -0,0 +1,39 @@ +[[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. +"""]] + +# Concepts + +A [[microkernel]] implements a minimal number of abstractions +that facilitate the realization of operating system services. + +[[Mach's_concepts|mach/concepts]] are documented here. + +Read OSF's Kernel Principles. Find it under the +[[mach/documentation]] link. + +# Exercises + +Mach's API is documented in OSF's Kernel API book. Find it +under the [[mach/documentation]] link. Skim it to get an idea +of how the API looks and then try the following exercises: + +Send messages using Mach's IPC mechanism +([detailed description](http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt)). + +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. diff --git a/microkernel/fud.mdwn b/microkernel/fud.mdwn new file mode 100644 index 00000000..bc2e366b --- /dev/null +++ b/microkernel/fud.mdwn @@ -0,0 +1,24 @@ +[[license text=""" +Copyright © 2002 Wolfgang Jährling and Jeroen Dekkers + +Verbatim copying and distribution of this entire article is permitted in any +medium, provided this notice is preserved. +"""]] + +# The Microkernel Experiment is Going On + +by [Wolfgang Jährling](mailto:wolfgang@pro-linux.de) and [Jeroen Dekkers](mailto:jeroen@dekkers.cx) + +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. + +Out of our own experience, we can confirm that the first generation microkernel Mach is quite slow, but being microkernel independent is one of the goals of the Hurd and people are already working on porting the Hurd from Mach to the second generation microkernel L4. Those new second generation kernels aren't as slow as Mach and we think that one should not talk about the performance of microkernel based systems without having read at least some of the papers on L4. The L4 people did some interesting benchmarks, which indicate that one can get a lot of performance by making a microkernel really small. How is this supposed to work? Well, the microkernel provides very primitive, highly optimized operations, and applications use them to implement whichever way of interprocess communication is apropriate for them in an efficient way. By deciding this on a per-case basis, you get optimal performance for all applications. + +But L4 takes this even further. For example, you can have schedulers in userspace. Therefore you can use a scheduler which is optimized for the specific tasks your system performs. With the Linux kernel, different schedulers are only possible by using a different source tree, thus you cannot switch at run-time and/or have different schedulers for different groups of processes. + +Of course, microkernels still have some problems, mainly because we are bound to today's technology, and current processors have not been designed with microkernels in mind. On a processor that is not optimized for systems with monolithic kernels, where the currently still problematic overhead of context switches would vanish, microkernels would get another performance boost. This sounds like an excuse, but it is intended as a reminder about the fact that the problem is not the general concept of microkernels. However, the L4 people have done a lot of good hacks to work around all this and have reached reasonable performance already. + +All this could be discussed in arbitrary detail, but we won't do that now, as we have more urgent things to do than reacting on FUD about microkernels. So we will conclude by saying that it is too easy to claim that one design is fast and the other one is slow, but everything depends on how exactly a system is designed and implemented. Maybe microkernels will eventually turn out to be slower in almost any case; we doubt that, but who knows? But even then, a microkernel based system will offer enough other advantages so that people will prefer to use it in some cases. But on the other hand, history has shown that new concepts seldom replace old ones completely, but rather establish themselfes in addition to the old ones, therefore we will have the opportunity to argue about which concept is best at least for another couple of years.. or decades? + +If you are interested in research about the performance of microkernel based systems, visit <http://www.l4ka.org> and <http://os.inf.tu-dresden.de/L4/> diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn new file mode 100644 index 00000000..9da27269 --- /dev/null +++ b/microkernel/mach.mdwn @@ -0,0 +1,16 @@ +Mach is a so-called first generation [[microkernel]]. It is the +microkernel currently used by the [[Hurd]]. + +* [[Documentation]] +* [[Concepts]] +* [[History]] ([Torvalds, Tanenbaum Debate](http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html)) + +# Implementations + +* [[GNUMach]] +* [[OskitMach]] - A Once Successor of Mach based on OSKit +* [Apple's Darwin](http://developer.apple.com/darwin/) ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) (**non-free**) + +# Related + +* [[Mach_Interface_Generator|mig]] diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn new file mode 100644 index 00000000..f81e4e4f --- /dev/null +++ b/microkernel/mach/concepts.mdwn @@ -0,0 +1,7 @@ +[[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's API is well-[[documented|Mach/Documentation]].
\ No newline at end of file diff --git a/microkernel/mach/discussion.mdwn b/microkernel/mach/discussion.mdwn new file mode 100644 index 00000000..589e302d --- /dev/null +++ b/microkernel/mach/discussion.mdwn @@ -0,0 +1,23 @@ +## <a name="Maintenance_of_the_Mach_web"> Maintenance of the Mach web </a> + +**_Old discussions:_** [[WIKIHOMEURLMachTOPICrev13]] + +Interesting, for consistency sake I'll think about making your changes you made on the right hand side to the other web WebHome pages. I guess it's not critical that they are identical, but I was trying to keep them identical if possible. I also wanted it to be "light" enough feature wise that it doesn't overpower the page. You've added back a few of the features, so we obviously differ in how important you and I think these features are. That's OK, I'll think about it some more and we'll see what happens. + +Oh, I see you added back [[WebTopicList]] and [[WebPreferences]]. I purposely removed [[WebPreferences]] from the lists on the right because it has nothing to do with navigation. I also didn't think that people actually use topic names to navigate. If they do they could search for them. Keeping the number to four items instead of six and keeping the descriptions concise makes a big difference when I view the page. + +(goes off to think more...) + +and eat... ;-) + +-- [[Main/GrantBow]] - 29 Dec 2002 + +**_Reasons for my change:_** + +1. [[WebTopicList]] is a lot quicker than the [[WebIndex]] - brings down the load times and the load of the server +2. [[WebPreferences]] - users might be curious to see what can be modified. Changes should of course only be made in their home topics, like in %WIKIUSERNAME%. However, the [[WebPreferences]] can serve as an inspiration. Therefore we should perhaps make sure only the [[Main/TWikiAdminGroup]] members can alter the \*Preferences topics. +3. If you look closely I've also reordered the links. Shorter names first and long ones last, I tried to keep the descriptions brief and in proportional length as well. + +I don't know about you, but keeping the number of items to four rather than six doesn't really matter to me. The text is quite small and if it's the space we're after the [[WebStatistics]] does take up more than the navigation links. + +-- [[Main/JoachimNilsson]] - 29 Dec 2002 diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn new file mode 100644 index 00000000..bb91313c --- /dev/null +++ b/microkernel/mach/documentation.mdwn @@ -0,0 +1,19 @@ +[[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. +"""]] + +- 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) diff --git a/microkernel/mach/externalpagermechanism.mdwn b/microkernel/mach/externalpagermechanism.mdwn new file mode 100644 index 00000000..1ccab6c4 --- /dev/null +++ b/microkernel/mach/externalpagermechanism.mdwn @@ -0,0 +1,189 @@ +[[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/gnumach.mdwn b/microkernel/mach/gnumach.mdwn new file mode 100644 index 00000000..4e00df8c --- /dev/null +++ b/microkernel/mach/gnumach.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. +"""]] + +GNU Mach runs on x86 machines (it does not support 64-bit machines). GNU +Mach is currently used by the GNU [[Hurd]]. + +GNU Mach remains compatible with Mach 3.0. + +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. + +# Related Links + +* [[Building]] +* [[RevivalProject]] - GNU Mach Projects +* [[HardwareCompatibilityList]] +* [[Ports]] - Ports to other Architectures diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn new file mode 100644 index 00000000..a85490e2 --- /dev/null +++ b/microkernel/mach/gnumach/building.mdwn @@ -0,0 +1,98 @@ +# <a name="Building_GNUMach_GNU_Mach_from_S"> </a> Building [[GNUMach]] from Source + +If you want to build the [[GNUMach]] kernel yourself instead of just using a pre-built binary, follow these instructions. + +The unpacked source tree is around 20 MiB, and the build tree (with all drivers enabled) is around 50 MiB. + +## <a name="Getting_the_Source_Code"> Getting the Source Code </a> + +### <a name="Developers_s_rcs"> Developers's rcs </a> + +See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach + +(Most probably you want to get hold of the _GNU Mach 1 branch_ and not the trunk, which is also what we've done above.) + +You then have to create the automatically generatable files: + + $ ( cd gnumach && autoreconf --install ) + +### <a name="What_Debian_is_currently_using"> What Debian is currently using </a> + +See [here](http://packages.debian.net/source/unstable/gnumach). + + $ apt-get source gnumach + +Please see [[Distrib/DebianFAQ]] before using _apt-get source_. + +## <a name="Preparing_for_the_Build"> Preparing for the Build </a> + +### <a name="_on_Debian_systems"> ... on Debian systems </a> + +Building GNU Mach requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source gnumach package: + + # apt-get install build-essential fakeroot + # apt-get build-dep gnumach + +### <a name="_on_non_Debian_systems"> ... on non-Debian systems </a> + +Apart from the case that you only want to install GNU Mach's header files (see below), building GNU Mach requires you to have the Mach Interface Generator installed. See [[building_MIG|mig/Building]] about how to do that, then come back here. + +Additionally, building GNU Mach requires a C compiler, a standard C library and your favourite flavor of awk (gawk) and GNU make. + +## <a name="Building_and_Installing"> Building and Installing </a> + +### <a name="_Debian_deb_files"> ... Debian _.deb_ files </a> + +Change into the directory with the downloaded / unpacked _gnumach_ sources, e.g. + + $ cd gnumach-20050801 + +Start the build process with + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +[[GNUMach]] is now building. To use the new kernel, you must install the resulting _.deb_ package which is located one directory above the build directory and has a similar name as the build directory, e.g. + + # dpkg -i ../gnumach_20050801-4_hurd-i386.deb + +You can now reboot your computer and enjoy the new kernel. + +### <a name="_TODO_"> [TODO] </a> + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (_[...]/gnumach-1-branch_) and configure it: + + $ [...]/gnumach-1-branch/configure [TODO] + +Build the kernel image: + + $ make gnumach.gz + +Optionally run the (tiny) test suite: + + $ make check + +You can then install and use _gnumach.gz_. + +[TODO.] + +### <a name="Installing_only_the_Header_Files"> Installing only the Header Files </a> + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (_[...]/gnumach-1-branch_) and configure it: + + $ [...]/gnumach-1-branch/configure --prefix= + +Install the header files into e.g. _~/gnu/include/_: + + $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn b/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn new file mode 100644 index 00000000..c3f59af1 --- /dev/null +++ b/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn @@ -0,0 +1,61 @@ +[[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. +"""]] + +# CPU Architecture + +GNU Mach current only supports the `x86` architecture. `amd64` should -- in +theory -- as well work fine in `32-bit` compatibility mode, however in practice +there are problems with the chipsets used for such processors, so that booting +on such a system won't succeed. + +Support for running GNU Mach (and a complete GNU/Hurd system) in a +[Xen](http://www.cl.cam.ac.uk/research/srg/netos/xen/) `domU` (again on `x86` +only) is [[being_worked_on|Hurd/xen]]. + +# Memory + +GNU Mach will use a maximum of 1 GiB of RAM. If your system has more, +the surplus will silently be ignored. (In past times, this would hinder GNU +Mach from booting at all, but this has been fixed, so you no longer need to +apply GRUB's `uppermem` directive.) + +# Video Cards + +Debian distributes a version of [X.org](http://x.org/). 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. <!-- Sure? --[[tschwinge]] --> + +# Device Drivers + +[GNU Mach Reference Manual, +Configuration](http://www.gnu.org/software/hurd/gnumach-doc/Configuration.html) +contains a list of device drivers that are included in GNU Mach and elaborates +on the hardware devices they support. diff --git a/microkernel/mach/gnumach/hardwarecompatibilitylist/discussion.mdwn b/microkernel/mach/gnumach/hardwarecompatibilitylist/discussion.mdwn new file mode 100644 index 00000000..69ca3190 --- /dev/null +++ b/microkernel/mach/gnumach/hardwarecompatibilitylist/discussion.mdwn @@ -0,0 +1,4 @@ +Further information may still be found on +<http://www.nongnu.org/thug/gnumach_hardware.html> +and could perhaps be incorporated into that page. +--[[tschwinge]] diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn new file mode 100644 index 00000000..9c9e5515 --- /dev/null +++ b/microkernel/mach/gnumach/ports.mdwn @@ -0,0 +1,18 @@ +[[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. +"""]] + +* [PowerPC](http://www.pjbruin.dds.nl/hurd/) diff --git a/microkernel/mach/gnumach/revivalproject.mdwn b/microkernel/mach/gnumach/revivalproject.mdwn new file mode 100644 index 00000000..b04b695f --- /dev/null +++ b/microkernel/mach/gnumach/revivalproject.mdwn @@ -0,0 +1,51 @@ +## <a name="GNU_Mach_Revival_Project"> </a> GNU Mach Revival Project + +This page is a place to keep track of all those things that we need to improve in GNU Mach, so that it is a reliable microkernel for The Hurd, both in terms of stability and performance. If you find anything missing here, please feel free to add a entry with a short description. + +If you want to help with any of the task (thanks!), please send a mail to the mailing list <http://www.gnu.org/software/hurd/help.html#TOCmail> stating what task you wish to work on, so that no duplicate efforts end up. + +**_Task List_** + +* Clean up the Code. (Assigned to: **Team Leader:** _Gianluca Guida (gianluca)_, **Hackers:** _Alfredo Beaumont (abeaumont)_, _Pedro J. Ruiz Lopez (holzplatten)_, _Matheus Morais (xsun)_, _We need **YOU** here!_) + * Remove all dead files from the GNU Mach source tree. + * Restructure the tree in a sane way. + * Remove dead functions/variables/etc from source files. + * Rewrite ugly code. + +* Update the core architecture and drivers. (Assigned to: **Team Leader:** _Gianluca Guida (gianluca)_, **Hackers:** _Alfredo Beaumont (abeaumont)_, _Sergio Lopez (koro)_, _Pedro J. Ruiz Lopez (holzplatten)_, _We need **YOU** here!_) + * Check what NetBSD, FreeBSD and Linux do with their host specific code (i486, PPC, Sparc, ...). And if it might be wise to take that and use it in GNU Mach. There is no need to worry about purely internal API's, but the external ones shouldn't require any major changes. + * Write a list of all functions provided by the host dependant code in GNU Mach that gets used in the non-host specific code (kernel, IPC and VM). + * Once we have decided what the new internal API should look like, make a list of the new API and the old one, and try to make things as compatible as possible, but not at the expense of anything. + +* Implement Migrating Threads. (Assigned to: _Sergio Lopez (koro)_) + * Migrating Threads (MT) could improve IPC performance and making easier the work of the scheduler. For more information, check this <http://www.usenix.org/publications/library/proceedings/sf94/ford.html> + +* Improve the external pagers interface. (Assigned to: _We need **YOU** here!_) + * Making this interface synchronous should improve I/O performance significantly, without (almost) any drawbacks (we also get some advantage from MT's). + * Implement more paging eviction policies, so they fit better with usual behaviour of the pagers. + * Implement resource accounting for external pagers. + +* VM. (Assigned to: _We need **YOU** here!_) + * Put it on user level (?) + * Clean up the mess. + * Provide a fast way to read/write from/to a memory object. + * Simplify/normalise the code. + +* Simplify the IPC Semantics. (Assigned to: _We need **YOU** here!_) + * There are a lot of things in GNU Mach's IPC that we don't need. Track down those things, and get rid of them without requiring many changes in the Hurd (the changes will affect MiG, but that is OK). + +* Temporary mappings for Client-Server memory transfers. (Assigned to: _We need **YOU** here!_) + * Extend Mach's IPC to provide some kind of object which can represent a range of memory that can temporarily be mapped into the servers address space for sending/receiving data. This would allow us to avoid excessive memory copies. + * Find a new way to work with unaligned memory. + +* GDB remote debugging support (Assigned to: _Alfred M. Szmidt (ams)_) + * Implement support for GDB debugging via serial line and/or network. Maybe this can be done together with the host-specific work above. + +**_Wish List_** + +* Interface for userspace non-critical drivers. +* Sound Support ;-) +* WLAN support (ipw2200) with WEP/WPA +* ACPI support + +-- [[Main/SergioLopez]] - 20 Dec 2005 (Corrections by Alfred M. Szmidt) diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn new file mode 100644 index 00000000..fe3247df --- /dev/null +++ b/microkernel/mach/history.mdwn @@ -0,0 +1,59 @@ +# <a name="Table_of_Contents"> Table of Contents </a> + +%TOC% + +# <a name="Early_beginnings"> Early beginnings </a> + +Mach has quite a history. Everything actually started at the University of Rochester in 1975. It was invented to demonstrate how operating systems could be built using a modular design where processes communicated using message passing, even across networks. The system was called the Rochester Intelligent Gateway and ran on a 16 bit mini computer called Eclipse from Data General. + +One of the engineers behind the project was Richard Rashid. In 1979 he moved his socks to Carnegie Mellon University to continue his research on message passing operating systems. The result emerged in 1981 and was called Accent. + +Accent kept running at CMU until 1984 but was by then being run over by UNIX. Rashid then decided to use an early embrace strategy and started designing the third generation OS project called Mach. By making Mach compatible with UNIX, Mach was supposed to gain a lot of available UNIX software. + +Mach was a vast improvement over Accent. It incorporated parts commonly used today, such as: threads, better IPC, multiprocessor support and an advanced VM system. + +At the time of Mach's conception, DARPA was seeking a multiprocessor (MP) capable OS and found Mach. With money from the Dept. of Defense, 4.2BSD support was added, to bloat the kernel; but most of all, to add complete UNIX compatibility. + +Now enters the UNIX war. + +UNIX was owned by AT&T which controlled the market almost completely. Industry giants such as IBM, DEC and H got together and formed the Open Software Foundation, OSF. In an effort to conquer market share, OSF took the Mach 2.5 release and made it the OSF/1 system. By that time Mach contained a lot of BSD and AT&T code but the OSF hoped that it would be able to take control of the rudder with OSF/1. What happens after that is a story better told by someone else ... + +In 1989 CMU decided to revamp Mach. They removed the bloat and put the UNIX emulation in user space making the Mach 3.0 release -- the pure Mach release. + +Later on support for Mach 3.0 at CMU vaned and the project was taken over by the University of Utah. The FLUX group started the Mach4 project. An ambitious project which included complete rewrite of the x86 support code and integration of Linux 2.0 drivers. That's right, Linux awoke around 1991 so this makes it apx. 1994. + +# <a name="GNU_Mach_and_OSKit_Mach"> </a> GNU Mach and OSKit-Mach + +GNU Mach is based on Mach4 from University of Utah, which in turn is based on Mach3 from Carnegie-Mellon University. The last release of Mach4 was the [UK22 release](http://www.cs.utah.edu/flux/mach4-i386/html/mach4-UK22.html). + +The OSKit was what evolved when the Mach4 project at University of Utah was dropped. The people involved wanted to reuse the work they had put into Mach in the form of hardware support and drivers. + +The oskit-mach version of GNU Mach was presented in November 1999 by Roland McGrath. <http://mail.gnu.org/pipermail/bug-hurd/1999-November/003554.html> The purpose of the port was to get better hardware support through new drivers and platform code available in the OSKit. + +On May 27 2002, after the Gnumach 1.3 release, Roland McGrath merged OSKit-Mach onto the HEAD of CVS making it the Gnumach 2.x mainline. + +Meanwhile, OSKit became unmaintained, thus posing more of a burden on than being helpful in GNU Mach development. Consequently, as of March 2006, nobody is working on OSKit Mach, or trying to use it. + +In 2005 Gianluca Guida started a different attempt to use the osenv interface with minimal changes to GNU Mach 1.x, thus allowing use of the generic driver interface while importing as little of the umaintained OSKit code as possible. However, there turned out to be serious problems with OSKit, so this attempt was abandoned as well. + +Today, GNU Mach development focuses on the 1.x branch again -- see also [[gnumach/RevivalProject]]. + +# <a name="Status_of_the_project"> Status of the project </a> + +GNU Mach 1.3 was released in May 2002, and features advanced boot script support, support for large disks (>= 10GB) and an improved console. + +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 (plus some backports of more recent drivers), so most newer hardware is not supported. + +As of March 2006 a GNU Mach 1.4 release is planned, focusing on code cleanup. It is meant to serve as a starting point for more radical future changes while maintaining 1.4.x as a stable branch. + +---- + +Copyright (C) 2001 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]] - 24 Oct 2002 + +Apple's Macintosh OSX (OS 10.x) is based on [Darwin](http://www.apple.com/macosx/technologies/darwin.html). _"Darwin uses a monolithic kernel based on [[TWiki/FreeBSD]] 4.4 and the OSF/mk Mach 3."_ Darwin also has a [Kernel Programming](http://developer.apple.com/techpubs/macosx/Darwin/General/KernelProgramming/About/index.html) Book. + +-- [[Main/GrantBow]] - 22 Oct 2002 diff --git a/microkernel/mach/ipc.mdwn b/microkernel/mach/ipc.mdwn new file mode 100644 index 00000000..01a9a891 --- /dev/null +++ b/microkernel/mach/ipc.mdwn @@ -0,0 +1,22 @@ +[[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. +"""]] + +An IPC is sent by invoking a [[port]]. + +[The Unofficial GNU Mach IPC beginner's guide](http://www.nongnu.org/hurdextras/ipc_guide/ipc_guide.html) + +[[General_information|/ipc]] about IPC. diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn new file mode 100644 index 00000000..b15b8f50 --- /dev/null +++ b/microkernel/mach/mig.mdwn @@ -0,0 +1,10 @@ +The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an +interface definition, it creates stubs to [[invoke]] object methods +and to demultiplex incoming messages. These stubs conveniently hide +the details of Mach's [[IPC]] machinery. + +GNU MIG is fully compatible with OSF MIG. + +* MIG's [homepage](http://www.gnu.org/software/hurd/mig.html) +* [[Documentation]] +* [[Building]] - Building (and obtaining) MIG diff --git a/microkernel/mach/mig/WebPreferences/logo.png b/microkernel/mach/mig/WebPreferences/logo.png Binary files differnew file mode 100644 index 00000000..cdfec179 --- /dev/null +++ b/microkernel/mach/mig/WebPreferences/logo.png diff --git a/microkernel/mach/mig/building.mdwn b/microkernel/mach/mig/building.mdwn new file mode 100644 index 00000000..08a1c14b --- /dev/null +++ b/microkernel/mach/mig/building.mdwn @@ -0,0 +1,71 @@ +# <a name="Building_the_Mach_Interface_Gene"> Building the Mach Interface Generator from Source </a> + +If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. + +## <a name="Getting_the_Source_Code"> Getting the Source Code </a> + +You can chose between getting the [sources from the developers's rcs](http://www.gnu.org/software/hurd/mig-download.html#cvs): + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig + +... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): + + $ apt-get source mig + +Please see [[Distrib/DebianFAQ]] before using _apt-get source_. + +The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. + +## <a name="Preparing_for_the_Build"> Preparing for the Build </a> + +### <a name="_on_Debian_systems"> ... on Debian systems </a> + +Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: + + # apt-get install build-essential fakeroot + # apt-get build-dep mig + +### <a name="_on_non_Debian_systems"> ... on non-Debian systems </a> + +Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. + +Additionally, you need to have GNU Mach's header files installed. See [[mach/gnumach/building]] about how to do that, then come back here. + +## <a name="Building_and_Installing"> Building and Installing </a> + +### <a name="_a_deb_file"> ... a _.deb_ file </a> + +Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): + + $ cd mig-1.3.1.99 + +Start the build process: + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +You can then install / distribute the _.deb_ file which will drop out one directory above the current one. + +### <a name="_TODO_"> [TODO] </a> + +The Mach Interface Generator has to be built in a separate directory: + + $ mkdir mig-build + $ cd mig-build + +Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: + + $ GNU=~/gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" + +Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: + + $ make all install + +To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: + + PATH=~/gnu/bin:$PATH + export PATH + +If you already have e.g. _~/bin_ in your _$PATH_, you could also create a symbolic link: + + $ ln -s ~/gnu/bin/mig ~/bin/ diff --git a/microkernel/mach/mig/discussion.mdwn b/microkernel/mach/mig/discussion.mdwn new file mode 100644 index 00000000..fdab3a45 --- /dev/null +++ b/microkernel/mach/mig/discussion.mdwn @@ -0,0 +1,17 @@ +Created + +-- [[Main/JoachimNilsson]] - 29 Oct 2002 + +The logo seems very programmer friendly as this web topic is intended. + +-- [[Main/GrantBow]] - 15 Nov 2002 + +There's little traffic here and little content. Perhaps we should just remove this web? It seemed like a good idea to create it when we split the others off... + +-- [[Main/GrantBow]] - 22 Dec 2002 + +Maybe, but not yet. Let's keep it for a while longer - say, three months. 1st April 2003. If the traffic still is low then we move the Mig topics to the Mach web ... + +...Mig = **Mach** Interface Generator. + +-- [[Main/JoachimNilsson]] - 22 Dec 2002 diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn new file mode 100644 index 00000000..222f89d1 --- /dev/null +++ b/microkernel/mach/mig/documentation.mdwn @@ -0,0 +1,27 @@ +[[toc ]] + +# About + +This is a small collection of links to external documents describing the Mach Interface Generator used by GNU Mach. + +# MIG and C Thread Programming + +A tutorial which demonstrates the use of the C Threads library primitives in writing a multithreaded program and the use of the Mach Interface Generator (MIG) to generate remote procedure calls for interprocess communication. Like its companion tutorial, it is based on the Mach 2.5 system. However, the concepts are applicable to Mach 3.0 user level programming. + +Linda R. Walmer and Mary R. Thompson. **A Programmer's Guide to the Mach User Environment**. [PostScript ](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.ps)[Doc](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.doc) February 1988. School of Computer Science, Carnegie Mellon University. + +An ftp directory containing the [mig programming examples](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig_example) for this tutorial. + +Slides to Rich Drave's talk on Mig, the Mach Interface Generator, on November 21, 1991: [PostScript](ftp://ftp.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/root.ps) [TeX](ftp://ftp.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/slides.tex) + +# Roots + +Mig is an implementation of a subset of the Matchmaker **language**. + +"Matchmaker is a language for specifying and automating the generation of multilingual interprocess communication interfaces. MIG is an interim implementation of a subset of the Matchmaker language that generates C and C++ remote procedure call interfaces for interprocess communication between Mach tasks." + +Richard P. Draves,Michael B. Jones,Mary R. Thompson, **MIG - THE MACH INTERFACE GENERATOR**. [ps](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps) [doc](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.doc) November 1989. Department of Computer Science, Carnegie-Mellon University. + +# Related Work + +See the citations about [Mach and matchmaker: kernel and language support for objectoriented distributed systems](http://citeseer.ist.psu.edu/context/93073/0) here. "M. B. Jones and R. F. Rashid, \`Mach and matchmaker: kernel and language support for objectoriented distributed systems', Proceedings of the Conference on Object-Oriented Programming Systems, Languages, and Applications, October 1986, pp. 67--77." diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn new file mode 100644 index 00000000..47ef427a --- /dev/null +++ b/microkernel/mach/port.mdwn @@ -0,0 +1,48 @@ +[[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. +"""]] + +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. diff --git a/microkernel/research.mdwn b/microkernel/research.mdwn new file mode 100644 index 00000000..4eefe602 --- /dev/null +++ b/microkernel/research.mdwn @@ -0,0 +1,15 @@ +## <a name="Research"> Research </a> + +Listed here are references to academical research papers related to Micro Kernels. + +* [Networking Performance for Microkernels](http://citeseer.nj.nec.com/maeda92networking.html) (1992) -- An article by Chris Maeda and Brian N. Bershad discussing microkernel optimizations of an UDP driver. + +* [The Increasing Irrelevance of IPC Performance for Microkernel-Based Operating Systems](http://citeseer.nj.nec.com/bershad92increasing.html) (1992) + +* [Linux Device Driver Emulation in Mach](http://citeseer.nj.nec.com/goel96linux.html) (1996) + +* [Microkernels Meet Recursive Virtual Machines](http://citeseer.nj.nec.com/ford96microkernel.html) (1996) + +* [The Flux OS Toolkit: Reusable Components for OS Implementation](http://citeseer.nj.nec.com/ford97flux.html) (1997) + +* [The Flux OSKit: A Substrate for Kernel and Language Research](http://www.cs.utah.edu/flux/papers/oskit-sosp97.html) (1997) |
