diff options
| author | Thomas Schwinge <thomas@codesourcery.com> | 2012-05-24 23:08:09 +0200 |
|---|---|---|
| committer | Thomas Schwinge <thomas@codesourcery.com> | 2012-05-24 23:08:09 +0200 |
| commit | 2910b7c5b1d55bc304344b584a25ea571a9075fb (patch) | |
| tree | bfbfbc98d4c0e205d2726fa44170a16e8421855e /microkernel | |
| parent | 35b719f54c96778f571984065579625bc9f15bf5 (diff) | |
Prepare toolchain/logs/master branch.
Diffstat (limited to 'microkernel')
63 files changed, 0 insertions, 3580 deletions
diff --git a/microkernel/barrelfish.mdwn b/microkernel/barrelfish.mdwn deleted file mode 100644 index 8cf5591b..00000000 --- a/microkernel/barrelfish.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -<http://barrelfish.org/> - - * {{$fof_plos09}} - - -[[!ymlfront data=""" - -fof_plos09: - - "Pierre-Evariste Dagand, Andrew Baumann, Timothy Roscoe. Filet-o-Fish: - practical and dependable domain-specific languages for OS development. PLOS - '09, October 11, 2009, Big Sky, Montana, USA." - -"""]] diff --git a/microkernel/coyotos.mdwn b/microkernel/coyotos.mdwn deleted file mode 100644 index fec023ba..00000000 --- a/microkernel/coyotos.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!meta title="Coyotos"]] - -[*Coyotos*](http://www.coyotos.org/) is a microkernel and OS and the successor -of [[EROS]], that itself is the successor of [[KeyKOS]]. A more complete -history can be found [here](http://www.coyotos.org/history.html). Its main -objectives are to correcte some shortcomings of [[EROS]], demonstrate that an -atomic kernel design scales well, and (eventually) to completely formally -verify both the kernel and critical system components by writing them in a new -language called [bitc](http://www.bitc-lang.org/). - -Coyotos is an orthogonally [[persistent|persistency]] pure [[capability]] -system. It uses [[continuation]]-based unbuffered asynchronous [[IPC]] -(actually it's synchronous [[IPC]] with asynchronous [[system calls]]). - -TODO: explain these terms and (more important) their consequences on system -design. - -The coyotos microkernel specification can be found -[here](http://www.coyotos.org/docs/ukernel/spec.html). - -There once was the idea of a GNU/Hurd [[port using the Coyotos -microkernel|history/port_to_another_microkernel]], but this didn't come live. diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn deleted file mode 100644 index a5a73e18..00000000 --- a/microkernel/discussion.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - -IRC, freenode, #hurd, 2011-07-26: - - < antrik> Tekk_`: regarding microkernels: the basic idea, and really the - *only* fundamental difference, is that they isolate things in separate - address spaces. everything else goes back to this. - < antrik> benefits from the isolation generally fall into two groups: more - robustness (main focus of Minix3), and more flexibility (main focus of - Hurd) - < antrik> while it might also encourage some other good design choices, - these are secondary effects: such choices can also be implemented in a - monolithic architecture -- and not necessarily harder. just less obvious - in some cases... diff --git a/microkernel/eros.mdwn b/microkernel/eros.mdwn deleted file mode 100644 index be1ca90a..00000000 --- a/microkernel/eros.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - -<http://www.eros-os.org/> - -TODO. <http://www.eros-os.org/essays/reliability/paper.html> diff --git a/microkernel/faq.mdwn b/microkernel/faq.mdwn deleted file mode 100644 index fe259f05..00000000 --- a/microkernel/faq.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!meta title="Microkernel FAQ"]] - -See also other [[/FAQ]]. - -[[!inline -pages="microkernel/faq/* and !*/discussion" -show=0 -feeds=no -actions=yes -rootpage="microkernel/faq" postformtext="Add a new item titled:"]] diff --git a/microkernel/faq/multiserver_microkernel.mdwn b/microkernel/faq/multiserver_microkernel.mdwn deleted file mode 100644 index ca9b2179..00000000 --- a/microkernel/faq/multiserver_microkernel.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2008, 2009 Free -Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!meta title="What is a Multiserver Microkernel?"]] - -A Microkernel has nothing to do with the size of the kernel. Rather, it refers -to the functionality that the kernel provides. It is generally agreed that -this is; a set of interfaces to allow processes to communicate and a way to -talk to the hardware. *Software drivers*, as we like to call them, are then -implemented in user space as servers. The most obvious examples of these are -the TCP/IP stack, the ext2 filesystem and NFS. In the case of the Hurd, users -now have access to functionality that, in a monolithic kernel, they could never -use, but now, because the server runs in user space as the user that started -it, they may, for instance, mount an FTP filesystem in their home directory. - -For more information about the design of the Hurd, read the paper by Thomas -Bushnell, BSG: -[[Towards_a_New_Strategy_of_OS_Design|hurd-paper]]. diff --git a/microkernel/for_beginners.mdwn b/microkernel/for_beginners.mdwn deleted file mode 100644 index ad50425e..00000000 --- a/microkernel/for_beginners.mdwn +++ /dev/null @@ -1,32 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -# 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 deleted file mode 100644 index 3f9229aa..00000000 --- a/microkernel/fud.mdwn +++ /dev/null @@ -1,34 +0,0 @@ -[[!meta copyright="Copyright © 2002 Wolfgang Jährling and Jeroen Dekkers"]] - -[[!meta license="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 -inter-process 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 themselves 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/l4.mdwn b/microkernel/l4.mdwn deleted file mode 100644 index 7af5e6fc..00000000 --- a/microkernel/l4.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -[[!meta copyright="Copyright © 2004, 2006, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -The [*L4* microkernel](http://l4ka.org/) is an attempt to create a very small -high performace core which provides basic memory management, task and context -switching, and little else. - -[L4Ka Pistachio Home](http://l4ka.org/projects/pistachio/). - -See [l4.verified](http://nicta.com.au/research/projects/l4.verified) for work -on formally verifying an L4 microkernel. - - * {{$sel4}} - -There was a GNU/Hurd [[port to L4|history/port_to_another_microkernel]], which -is now stalled. - - -[[!ymlfront data=""" - -sel4: - - "G. Klein, K. Elphinstone, G. Heiser, J. Andronick, D. Cock, P. Derrin, - D. Elkaduwe, K. Engelhardt, R. Kolanski, M. Norrish, T. Sewell, H. Tuch, and - S. Winwood. seL4: Formal verification of an OS kernel. In Proceedings of - the ACM Symposium on OS Principles, Big Sky, MT, USA, October 2009." - -"""]] diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn deleted file mode 100644 index deaf6788..00000000 --- a/microkernel/mach.mdwn +++ /dev/null @@ -1,92 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Mach is a so-called first generation [[microkernel]]. It is the -microkernel currently used by the [[Hurd]]. - - * [[Concepts]] - - * [[Documentation]] - - * [[History]] - - * [Torvalds, Tanenbaum - Debate](http://www.dina.dk/~abraham/Linus_vs_Tanenbaum.html) - - -# Implementations - - * [[GNU_Mach|gnumach]] - - * [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)|mig]] - - -[[!ymlfront data=""" - -kernel_foundation_unix: - - "M. Accetta, R. Baron, W. Bolosky, D. Golub, R. Rashid, A. Tevanian, and - M. Young, Mach: A New Kernel Foundation for UNIX Development, USENIX - Conference Proceedings, July 1986. Paper - [\[pdf\]](http://www.cs.toronto.edu/~demke/469F.06/Handouts/mach_usenix86.pdf)." - -kernel_interface: - - "Mach 3 Kernel Interfaces. Open Software Foundation and Carnegie Mellon - University. Keith Loepere, Editor. NORMA-MK12: July 15, 1992. Book [\[ps - (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps), - [\[ps - (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps)." - -kernel_principles: - - "Mach 3 Kernel Principles. Open Software Foundation and Carnegie Mellon - University. Keith Loepere. NORMA-MK12: July 15, 1992. Book [\[ps - (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps), - [\[ps - (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps)." - -server_interface: - - "Mach 3 Server Writer’s Interfaces. Open Software Foundation and Carnegie - Mellon University. Keith Loepere, Editor. NORMA-MK12, user15: July 15, - 1992. Book [\[ps - (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps), - [\[ps - (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps)." - -server_writer: - - "Mach 3 Server Writer’s Guide. Open Software Foundation and Carnegie Mellon - University. Keith Loepere, Editor. NORMA-MK12, user15: July 15, 1992. Book - [\[ps - (HTTP)\]](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps), - [\[ps - (FTP)\]](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps)." - -vm: - - "R. Rashid, A. Tevanian, M. Young, D. Golub, and R. Baron, - Machine-Independent Virtual Memory Management for Paged Uniprocessor and - Multiprocessor Architectures, 2nd ACM Symposium on Architectural Support for - Programming Languages and Operating Systems (ASPLOS), October 1987. Paper - [\[pdf\]](http://citeseerx.ist.psu.edu/viewdoc/download?doi=10.1.1.111.7918&rep=rep1&type=pdf), - presentation - [\[ppt\]](http://www2.cs.uh.edu/~paris/6360/PowerPoint/Mach.ppt)." - -"""]] diff --git a/microkernel/mach/concepts.mdwn b/microkernel/mach/concepts.mdwn deleted file mode 100644 index 0f7cbf00..00000000 --- a/microkernel/mach/concepts.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2007, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[Mach]] is a first-generation [[microkernel]]. - -Mach's basic abstractions include [[virtual_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]]. - -Controlling [[task]]s, their [[virtual_address_space]], [[thread]]s, and other -system objects in Mach is implemented by using [[port]]s, as opposed to other -[[kernel]]s' [[system_call]] interface: almost all of the Mach API is -implemented by sending [[message]]s to [[port]]s. Device drivers that reside -in kernel space are controlled by ports, too. - -Mach's [[API]] is well-[[documented|documentation]]. - -[[!toggleable id=mach_kernel_principles text="""[[!template id=note -text="*[[mach\_kernel\_principles|documentation]]*: -{{$mach#kernel_principles}}"]]"""]] - -In particular the [[!toggle id=mach_kernel_principles -text="[mach\_kernel\_principles]"]] book further elaborates on Mach's concepts -and principles. diff --git a/microkernel/mach/continuation.mdwn b/microkernel/mach/continuation.mdwn deleted file mode 100644 index 7a3267f3..00000000 --- a/microkernel/mach/continuation.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[Mach]] internally uses *continuation*s for kernel [[thread]] management. - -The advantage is that not a full kernel thread stack has to be preserved in -case that a thread is about to enter a blocking state. This saves space. It -is not clear this is still worthwhile given today's RAM offerings. (How many -kernel threads are there, typically?) - -And, this would no longer be possible in case Mach were be made a -[[preemptive|preemtion]] kernel. In the latter case, the kernel itself, that -is, kernel threads can be preempted, and then their full state needs to be -preserved. - -[[!tag open_issue_documentation]] <!-- Not linked to from any Mach page. Move -to GNU Mach pages, as this is only an implementation detail? --> diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn deleted file mode 100644 index cc880ab6..00000000 --- a/microkernel/mach/documentation.mdwn +++ /dev/null @@ -1,49 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008, -2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - - * Mach's [[concepts]]. - - * [*Meet Mach* by James - Scott](http://beefchunk.com/documentation/macosx-programming/Meet_Mach.pdf), - a summary of Mach's history and main concepts. - - * *[[The_GNU_Mach_Reference_Manual|gnumach/reference_manual]]*. - - * {{$mach#kernel_foundation_unix}} - - * {{$mach#vm}} - - * {{$mach#kernel_principles}} - - * {{$mach#kernel_interface}} - - * {{$mach#server_writer}} - - * {{$mach#server_interface}} - - * [*The Unofficial GNU Mach IPC beginner's - guide*](http://hurdextras.nongnu.org/ipc_guide/), an easy introduction to - Inter Process Comunication in the Mach microkernel by Manuel Pavón - Valderrama. - - * [*Mach IPC without - MIG*](http://walfield.org/pub/people/neal/papers/hurd-misc/mach-ipc-without-mig.txt), - an exercise by Neal Walfield *to understand Mach IPC at one of its lowest - application levels*. - - * [*ipc-hello.c*](http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c): - *Hello world à la mach ipc*. - - - [Porting and Modifying the Mach 3.0 Microkernel](http://shakthimaan.com/downloads/hurd/Porting%20and%20Modifying%20the%20Mach%203.0%20Microkernel.pdf) - - - [An IO System for Mach](http://shakthimaan.com/downloads/hurd/An%20IO%20System%20for%20Mach.pdf) - - - [A Programmers' Guide to Mach System Call](http://shakthimaan.com/downloads/hurd/A.Programmers.Guide.to.the.Mach.System.Calls.pdf) diff --git a/microkernel/mach/external_pager_mechanism.mdwn b/microkernel/mach/external_pager_mechanism.mdwn deleted file mode 100644 index 05a6cc56..00000000 --- a/microkernel/mach/external_pager_mechanism.mdwn +++ /dev/null @@ -1,195 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -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 processes do the -latter. - -[[!tag open_issue_documentation]] <!-- Should probably refer to {{$mach#vm}}. ---> - - -# Introduction - -In Mach, a [[task]]'s [[virtual_address_space]] consists of references to -[[memory_object]]s. - -To associate a memory object with a portion of a task's -address space, `vm_map` is invoked on 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|page_fault]], 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's address space 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|page_fault]]. 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 [[hurd/libstore]] library which is used to -transparently manage block devices. The [[hurd/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 server 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` <!-- doesn't exist --> 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 server which -eventually sends it to disk. The device driver consumes the memory -doing the equivalent of a `vm_deallocate`. - - -# Issues - - * [[open_issues/performance/io_system/read-ahead]] - - * [[open_issues/performance/io_system/clustered_page_faults]] - - -# GNU Hurd Usage - -Read about the [[Hurd's I/O path|hurd/io_path]]. diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn deleted file mode 100644 index edd0cfdb..00000000 --- a/microkernel/mach/gnumach.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2007, 2008, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -GNU Mach is the microkernel upon which a GNU Hurd system is based. It provides -an Inter Process Communication (IPC) mechanism that the Hurd uses to define -interfaces for implementing in a distributed multi-server fashion the services -a traditional operating system kernel provides. - -It is maintained by the Hurd developers for the GNU project and remains -compatible with [[Mach]] 3.0. - -The majority of GNU Mach's [[device_driver]]s are from Linux 2.0. They were -added using glue code, i.e., a Linux [[emulation]] layer in Mach. - -GNU Mach runs on x86 machines. See the -[[hardware_compatibility_list]] and information about -[[ports]] to other architectures. - - -# 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 [[interface]]s and some -features which make it useful as the base of the [[Hurd]] system. - - * **it's free software** - - Anybody can use, modify, and redistribute it under the terms of the - [[GNU_General_Public_License_(GPL)|gpl]]. - - * **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. - - * **it's scalable** - - 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). - - * **it exists** - - 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]]. - - -# Booting - -To actually use the kernel and boot the GNU operating system, you need a boot -loader. Not all boot loaders are capable to boot the GNU system, you need one -that supports the multiboot standard. The bootloader of the GNU system is -[[GNU_GRUB|grub]], which supports a broad range of operating systems including -GNU/Hurd. - - -# Development - - * [[Reference_Manual]] - * [[Building]] - * [[Debugging]] - * [[Boot_Trace]] - * [[Memory_Management]] - * [[Projects]] - * [[Rules]] - * [[Open Issues|tag/open_issue_gnumach]] diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn deleted file mode 100644 index 1badf712..00000000 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ /dev/null @@ -1,229 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -`if NCPUS > 1` stuff is not being considered so far. - - -> i386/i386at/boothdr.S: \_start - -> i386/i386at/boothdr.S: boot\_entry - ->> i386/i386at/model\_dep.c: c\_boot\_entry - ->>> i386/i386at/boothdr.S: discover\_x86\_cpu\_type - ->>> i386/i386at/model\_dep.c: i386at\_init - ->>>> i386/i386/pic.c: picinit - ->>>> i386/i386at/model\_dep.c: mem\_size\_init - ->>>> i386/intel/pmap.c: pmap\_bootstrap - ->>>> i386/i386/gdt.c: gdt\_init - ->>>> i386/i386/idt.c: idt\_init - ->>>> i386/i386at/int\_init.c: int\_init - ->>>> i386/i386/ldt.c: ldt\_init - ->>>> i386/i386/ktss.c: ktss\_init - ->>> kern/startup.c: setup\_main - ->>>> kern/debug.c: panic\_init - ->>>> kern/printf.c: printf\_init - ->>>> kern/sched\_prim.c: sched\_init - ->>>>> kern/sched\_prim.c: wait\_queue\_init - ->>>>> kern/processor.c: pset\_sys\_bootstrap - ->>>>> kern/ast.c: ast\_init - ->>>> vm/vm\_init.c: vm\_mem\_bootstrap - ->>>>> vm/vm\_resident.c: vm\_page\_bootstrap - ->>>>>> vm/vm\_resident.c: pmap\_startup - ->>>>> kern/zalloc.c: zone\_bootstrap - ->>>>> vm/vm\_object.c: vm\_object\_bootstrap - ->>>>>> vm/vm\_external.c: vm\_external\_module\_initialize - ->>>>> vm/vm\_map.c: vm\_map\_init - ->>>>> vm/vm\_kern.c: kmem\_init - ->>>>> i386/intel/pmap.c: pmap\_init - ->>>>> kern/zalloc.c: zone\_init - ->>>>> kern/kalloc.c: kalloc\_init - ->>>>> vm/vm\_fault.c: vm\_fault\_init - ->>>>> vm/vm\_resident.c: vm\_page\_module\_init - ->>>>> vm/memory\_object.c: memory\_manager\_default\_init - ->>>> ipc/ipc\_init.c: ipc\_bootstrap - ->>>>> ipc/ipc\_table.c: ipc\_table\_init - ->>>>> ipc/ipc\_notify.c: ipc\_notify\_init - ->>>>> ipc/ipc\_hash.c: ipc\_hash\_init - ->>>>> ipc/ipc\_marequest.c: ipc\_marequest\_init - ->>>> vm/vm\_init.c: vm\_mem\_init - ->>>>> vm/vm\_object.c: vm\_object\_init - ->>>> ipc/ipc\_init.c: ipc\_init - ->>>>> kern/ipc\_host.c: ipc\_host\_init - ->>>>>> kern/ipc\_host.c: ipc\_pset\_init - ->>>>>> kern/ipc\_host.c: ipc\_pset\_enable - ->>>>>> kern/ipc\_host.c: ipc\_processor\_init - ->>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL - ->>>> kern/timer.c: init\_timers - ->>>> kern/mach\_clock.c: init\_timeout - ->>>> kern/xpr.c: xprbootstrap - ->>>> kern/time\_stamp.c: timestamp\_init - ->>>> kern/mach\_clock.c: mapable\_time\_init - ->>>> i386/i386at/model\_dep.c: machine\_init - ->>>>> device/cons.c: cninit - ->>>>> i386/i386/fpu.c: init\_fpu - ->>>>> linux/dev/init/main.c: linux\_init - ->>>>>> linux/dev/arch/i386/kernel/irq.c: init\_IRQ - ->>>>>>> linux/dev/arch/i386/kernel/irq.c: reserve\_mach\_irqs - ->>>>>> linux/dev/kernel/sched.c: linux\_sched\_init - ->>>>>> linux/dev/init/main.c: calibrate\_delay - ->>>>>> linux/dev/glue/kmem.c: linux\_kmem\_init - ->>>>>> linux/src/drivers/pci/pci.c: pci\_init - ->>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_init - ->>>>>>> linux/src/drivers/pci/pci.c: scan\_bus - ->>>>>>> linux/src/arch/i386/kernel/bios32.c: pcibios\_fixup - ->>>>>> linux/dev/glue/net.c: linux\_net\_emulation\_init - ->>>>>> linux/dev/drivers/block/genhd.c: device\_setup - ->>>>>>> linux/dev/glue/block.c: blk\_dev\_init - ->>>>>>>> linux/src/drivers/block/ide.c: ide\_init - ->>>>>>>> linux/dev/drivers/block/floppy.c: floppy\_init - ->>>>>>> linux/src/drivers/scsi/scsi.c: scsi\_dev\_init - ->>>>>>> linux/dev/net/core/dev.c: net\_dev\_init - ->>>>>> linux/pcmcia-cs/glue/pcmcia.c: pcmcia\_init - ->>>>> i386/i386at/autoconf.c: probeio - ->>>>> i386/i386at/model\_dep.c: inittodr - ->>>>> i386/intel/pmap.c: pmap\_unmap\_page\_zero - ->>>> kern/task.c: task\_init - ->>>>> kern/syscall\_emulation.c: eml\_init - ->>>> kern/thread.c: thread\_init - ->>>>> i386/i386/pcb.c: pcb\_module\_init - ->>>>>> i386/i386/fpu.c: fpu\_module\_init - ->>>>>> i386/i386/iopb.c: iopb\_init - ->>>> kern/thread\_swap.c: swapper\_init - ->>>> kern/sched\_prim.c: recompute\_priorities - ->>>> kern/mach\_factor.c: compute\_mach\_factor - ->>>> kern/startup.c: start\_kernel\_threads - -[...] - ->>>> kern/startup.c: cpu\_launch\_first\_thread - ->>>>> i386/i386at/model\_dep.c: startrtclock - ->>>>>> i386/i386/pit.c: clkstart - ->>>>> i386/intel/pmap.h: PMAP\_ACTIVATE\_KERNEL - ->>>>> i386/i386/pcb.c: load\_context - -[...] - -> kern/startup.c: start\_kernel\_threads - -> Threads get created. - ->> kern/sched\_prim.c: idle\_thread - ->> One for each CPU. - ->> kern/thread.c: reaper\_thread - ->> kern/thread\_swap.c: swapin\_thread - ->> kern/sched\_prim.c: sched\_thread - ->> [...] - ->> kern/bootstrap.c: bootstrap\_create - ->>> The [[grub/multiboot]] modules have been put somewhere into memory by ->>> [[GRUB]]. The boot scripts are parsed. The modules' ELF image's `PT_LOAD` ->>> sections are \`\`read'' (that is, `vm_allocate` and `copyout`) and turned ->>> into real [[task]]s. The multiboot modules' memory regions can be ->>> deallocated then. - ->> [...] - ->> vm\_pageout - ->> Does not return. diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn deleted file mode 100644 index 427fb083..00000000 --- a/microkernel/mach/gnumach/building.mdwn +++ /dev/null @@ -1,119 +0,0 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -# Building [[GNU_Mach|gnumach]] from Source - -If you want to build the [[GNU_Mach|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. - -## Getting the Source Code - -You can either use the git repository (see <http://git.savannah.gnu.org/cgit/hurd/>), - - $ git clone http://git.savannah.gnu.org/cgit/hurd/gnumach.git/ - -... or get the Debian sources, if you're using Debian. (See -[here](http://packages.debian.net/source/unstable/gnumach).) - - $ apt-get source gnumach - -Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. - -## On Debian Systems: - -### Preparing for the Build - -Building GNU Mach requires the *build-essential* and *fakeroot* packages, -and some additional dependencies specified by the gnumach source package: - - # apt-get install build-essential fakeroot - # apt-get build-dep gnumach - -### Building and Installing ... Debian `.deb` files - -Change into the directory with the downloaded / unpacked GNU Mach sources, - - $ cd gnumach-XXXXXXXX - -Start the build process with - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -[[GNU_Mach|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: - - # dpkg -i ../gnumach_XXXXXXXX-X_hurd-i386.deb - -You can now reboot your computer and enjoy the new kernel. - -## On non-Debian Systems: - -### Preparing for the Build - -Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library, -your favourite flavor of awk (gawk) and GNU make. - -First, create the configuartion files: - - $ cd gnumach - $ autoreconf --install - -GNU Mach (and the associated headers) need be built in a separate build directory: - - $ mkdir build - $ cd build - -Run configure: - - $ ../configure --prefix= - -If building on a 64 bit host system, -you need a number of additional settings to force a 32 bit build: - - $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu - -### Installing the Header Files First - -In order to build GNU Mach, you will need a working MIG. -Building MIG in turn requires the GNU Mach header files to be already present. -So for bootstrapping MIG, you have to install the Mach headers first, -for example into `~/gnu/include/`: - - $ make DESTDIR=~/gnu install-data - -Now you can [[build_MIG|mig/gnu_mig/building]]. -Once you are done with that, come back here to finish the Mach build. - -### Building and Installing - -With MIG present, now build the kernel image: - - $ make gnumach.gz - -Optionally run the (tiny) test suite: - - $ make check - -It's a good idea to make a backup of the previously installed kernel, in case -you can't boot using the new one. That way, you can restore it after booting -from a rescue media (or mounting the disk image used by your vm). - - # cp /boot/gnumach.gz /boot/gnumach.gz.bak - -GNU Mach can now be moved into place, typically `/boot/gnumach.gz`, so that you -can boot your system with the new kernel. - - # cp gnumach.gz /boot - diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn deleted file mode 100644 index b57f0393..00000000 --- a/microkernel/mach/gnumach/debugging.mdwn +++ /dev/null @@ -1,145 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Here are some hints to debug with GNU Mach. - -[[!toc levels=2]] - - -# Kernel Debugger - -Mach has a built-in kernel debugger. -[Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). - -First, make sure to enable it. Either by using a pre-packaged gnumach-image-something-dbg, or by passing --enable-kdb to the ./configure invocation. - -Then, reproduce the issue again. If something like a kernel trap happens, you will end up in the GNU Mach debugger. Otherwise, type control-alt-d to make Mach enter it by hand. - -If you are running in kvm or qemu, it is convenient to use the curses frontend to be able to copy/paste. - -To get the register values, type - - show registers - -To get a backtrace, type trace, which will print both function return addresses and function parameters, such as - - 0x107cf1(8088488,5e,40000008,2aa008,0) - 0x1071bc(0,0,0,0,0) - 0x106831(24fe00,2000,b,800,0) - -Run the addr2line tool on the return addresses: - - $ addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 - -This will print the source code lines of the backtrace. - -To examine the backtrace of some given thread, use - - show all thread/u - -to get the whole listing of all tasks and threads. You can then use trace/t to trace a specific thread. - -Unfortunately, userland and kernelland use the same range of addresses, so one can not get userland traces easily. The Xen port uses different ranges, and in that case one can use trace/u to also get the userland trace. - -To examine a variable, use nm /boot/gnumach to get the address of the variable (e.g. 0x123400), and use - - x 0x123400 - -to read it. One can also write to it by using - - w 0x123400 - -Another interesting feature is watching a variable, by using - - watch 0x123400 - -and then type continue, to let Mach continue execution. The debugger will be entered again on any change in that variable. The watch is implemented in hardware, so it does not disturb or slow down execution at all. - - -# GDB in QEMU - -When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly -[use GDB on the running -kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48). - - -# Code Inside the Kernel - -Alternatively you can use an approach like this one: add the following code -snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top -of the function, and modify the code as needed. - - void D (char *s) - { - switch (s[0] - '0') - { - case 0: - printf ("Hello from %s!\n", __FUNCTION__); - break; - case 1: - printf ("%s: Invoking task_collect_scan.\n", __FUNCTION__); - extern void task_collect_scan (void); - task_collect_scan (); - break; - default: - printf ("No idea what you want me to do.\n"); - break; - } - } - - if (name && name[0] == 'D') - D (name + 1); - -Then boot your system and do something like this: - - # devprobe D0 - Hello from D! - # devprobe D1 - D: Invoking task_collect_scan. - # devprobe D2 - No idea what you want me to do. - -This is especially useful if you need to manually trigger some stuff inside the -running kernel, as with the *D1* example. - - -## Writing to the Screen Buffer - -If you're doing real low level debugging, you might want to put variations of -the following snipped into the code, this code will write a `#` character at -line `[LINE]`, column `[COLUMN]` on the screen: - - *((char *) 0xb8000 + 2 * ([LINE] * 80 + [COLUMN])) = '#'; - halt_cpu (); - -The call of `halt_cpu` will -- as the name suggests -- halt the system -afterwards. This might be what you want or it might not, but it is needed at -some place when running the kernel inside QEMU, as QEMU somehow decides not to -update its display buffer anymore under certain conditions. - - -# Halting the CPU and Examining Registers - -IRC, freenode, #hurd, 2011-07-14: - - <braunr> one ugly trick i use when printf isn't available is to halt the - cpu - <braunr> then use info registers to know where the cpu is halted - <braunr> and you'll know if you reached that code or not - <braunr> (info registers is a qemu command) - - -# Serial Console - -IRC, freenode, #hurd, 2011-11-13: - - <youpi> use console=com0 - <youpi> to activate the console on the first serial port diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn deleted file mode 100644 index 874f5f07..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ /dev/null @@ -1,112 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -# CPU Architecture - -GNU Mach current only supports the `x86` (alias `ia32` or `i386`) architecture. - -`amd64`/`ix64` should work in `32-bit` compatibility mode. However, in practice -`amd64` systems seem to be troublesome more often than not. This is probably -related to the same (chipset-related) problems we often see with recent -machines; but it seems that `amd64` ones use problematic chipsets particularily -often. So far we haven't heard of similar problems with Intel's eqivalent -`ix64` (or `EM64T` as it used to be called) -- but maybe that just means fewer -people tried running the Hurd on such machines :-) - -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|ports/xen]]. - -Read about further [[ports]]. - -# Memory - -GNU Mach will use a maximum of 1.7 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. - -Using an internal i815 videocard [won't -work](http://lists.debian.org/debian-hurd/2007/12/msg00007.html) (at least when -using the specialized driver), because of [missing AGP GART support in GNU -Mach](http://lists.debian.org/debian-hurd/2007/12/msg00011.html). - -# Sound - -No sound cards are supported at this time. - -# USB 1.1/2.0 - -USB is not supported at this time. - -However, USB-type keyboards and mice may (and have been reported to) work -nevertheless, given that the hardware / BIOS is doing emulation to the -supported legacy interfaces. - -# IEEE 1394 (Firewire) - -IEEE 1394 is not supported at this time - -# Storage - -All common IDE drives should work. Some drive geometries do not work, -e.g. drives with hundreds of GiB of storage space, see [[!GNU_Savannah_bug -26425]]. - - -## SATA - -SATA drives may work in compatibility mode. - -This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach -couldn't connect to the hard disk, e.g., in a SATA system without IDE -compatibility mode: - - start (hd0,3)/hurd/ext2fs.static: (hd0,3)/hurd/ext2fs.static - device:hd0s4: No such device or address - -There *may* be an option in the system's BIOS setup to configure enabling such -a compatibility mode. - - -# 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. - -# User Success Reports - -These boards are known to work. Gnumach/Hurd has been installed and run on these board successfully. - -* ASUS P2B motherboard with an Intel PII 450MHz CPU with Intel Pro/100 NIC in PCI slot -* Intel SE-440BX motherboard -* VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good. -* Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup. -* Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3. - -# User Failure Reports - -Some people couldn't get these hardware combinations to work with Hurd. - -Note: The Debian GNU/Hurd installer actually runs on Linux, so it (almost) always works. The critical bit is booting after installation. - -* ASUS P5A motherboard and AMD K6-2 333MHz CPU - doesn't boot -* ASUS P2B-LS motherboard with an Intel PII-MMX 400 MHz CPU - this board had a defective onboard NIC (that could not be disable in BIOS) and working 3COM Etherlink III NIC in a PCI bus slot. This combination worked with GNU/Linux. The 3COM NIC is known to work with the Hurd. However, while gnumach/Hurd will boot on this system, it is confused by the defective onboard NIC and unable to use the 3COM NIC. Attempting to start networking generates a continous stream of eth0 and eth1 reset messages on the console that renders the system unusable. -* ASrock 775Twins-HDTV with a Pentium D 810 (533 MGz FSB/2600GHz core -- information no longer present on intel's site). Doesn't boot. diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn deleted file mode 100644 index 2b65956a..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - -Further information may still be found on -<http://www.nongnu.org/thug/gnumach_hardware.html> -and could perhaps be incorporated into that page. ---[[tschwinge]] - - -# SATA - -IRC, freenode, +hurd, 2011-07-24 - - <braunr> youpi: concerning the ide compatibility problem, it seems some - bioses provide several modes - <braunr> youpi: "legacy ide" and "native ide" - <braunr> i don't know what native ide really means, but when debugging ide - probing in gnumach, it just looks like there is nothing to detect - <braunr> and even in this mode, linux uses the ahci driver - <youpi> apparently native means it still uses the IDE protocol, but - possibly with other IRQs - <youpi> i.e. you need a PCI driver to handle that - <braunr> ok diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn deleted file mode 100644 index ca2f42c4..00000000 --- a/microkernel/mach/gnumach/memory_management.mdwn +++ /dev/null @@ -1,104 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - -IRC, freenode, #hurd, 2011-02-15 - - <braunr> etenil: originally, mach had its own virtual space (the kernel - space) - <braunr> etenil: in order to use linux 2.0 drivers, it now directly maps - physical memory, as linux does - <braunr> etenil: but there is nothing similar to kmap() or vmalloc() in - mach, so the kernel is limited to its 1 GiB - <braunr> (3 GiB userspace / 1 GiB kernelspace) - <braunr> that's the short version, there is a vmalloc() in mach, but this - trick made it behave almost like a kmalloc() - <antrik> braunr: the direct mapping is *only* for the benefit of Linux - drivers?... - <braunr> also, the configuration of segments limits the kernel space - <braunr> antrik: i'm not sure, as i said, this is the short version - <braunr> antrik: but there is a paper which describes the integration of - those drivers in mach - <etenil> you mean the linux 2.0 drivers? - <antrik> braunr: I read it once, but I don't remember anything about the - physical mapping in there... - <antrik> etenil: well, originally it was 1.3, but essentially that's the - same... - <braunr> i don't see any other reason why there would be a direct mapping - <braunr> except for performance (because you can use larger - even very - lage - pages without resetting the mmu often thanks to global pages, but - that didn't exist at the time) - -IRC, freenode, #hurd, 2011-02-15 - - <antrik> however, the kernel won't work in 64 bit mode without some changes - to physical memory management - <braunr> and mmu management - <braunr> (but maybe that's what you meant by physical memory) - -IRC, freenode, #hurd, 2011-02-16 - - <braunr> antrik: youpi added it for xen, yes - <braunr> antrik: but you're right, since mach uses a direct mapped kernel - space, the true problem is the lack of linux-like highmem support - <braunr> which isn't required if the kernel space is really virtual - - ---- - -IRC, freenode, #hurd, 2011-06-09 - - <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the - user/kernel boundary address ? - <youpi> I did - <braunr> 2G ? - <youpi> yes - <braunr> ok - <youpi> it doesn't make so much sense to let processes have 3G addressing - space when there can't be more that 1G physical memory - <braunr> that's sad for an operating system which does most things by - mapping memory eh - <youpi> well, if a process wants to map crazy things, 3G may be tight - already - <youpi> e.g. ext2fs - <braunr> yes - <youpi> so there's little point in supporting them - <braunr> we need hurd/amd64 - <youpi> and there's quite some benefit in shrinking them to 2G - <youpi> yes - <youpi> actually even 2G may become a bit tight - <youpi> webkit linking needs about 1.5-2GiB - <youpi> things become really crazy - <braunr> wow - <braunr> i remember the linux support for 4G/4G split when there was enough - RAM to fill the kernel space with struct page entries - - -IRC, freenode, #hurd, 2011-11-12 - - <youpi> well, the Hurd doesn't "artificially" limits itself to 1.5GiB - memory - <youpi> i386 has only 4GiB addressing space - <youpi> we currently chose 2GiB for the kernel and 2GiB for the userspace - <youpi> since kernel needs some mappings, that leaves only 1.5GiB usable - physical memory - <sea4ever`> Hm? 2GiB for kernel, 2GiB for userspace, 500MiB are used for - what? - <youpi> for mappings - <youpi> such as device iomap - <youpi> contiguous buffer allocation - <youpi> and such things - <sea4ever`> Ah, ok. You map things in kernel space into user space then. - <youpi> linux does the same without the "bigmem" support - <youpi> no, just in kernel space - <youpi> kernel space is what determines how much physical memory you can - address - <youpi> unless using the linux-said-awful "bigmem" support diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn deleted file mode 100644 index f114460c..00000000 --- a/microkernel/mach/gnumach/ports.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - - * x86. This is the main port. - - * [[Xen]] - - * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. - - * Alpha: [project I](http://savannah.nongnu.org/projects/hurd-alpha), and - [project II](http://savannah.nongnu.org/projects/gnumach-alpha). Was once - started, but isn't in a usable state either. - - * MIPS. Status completely unknown. - - * [[open_issues/Mach_on_Top_of_POSIX]]. Status unknown. diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn deleted file mode 100644 index 5fe73c06..00000000 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ /dev/null @@ -1,127 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!toc]] - - -# Xen dom0, hypervisor - -/!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor. - -You can either get binaries at <http://youpibouh.thefreecat.org/hurd-xen/> or build them yourself. - -- Copy `gnumach-xen-pae` and `hurd-modules` to your dom0 /boot. If you still have a non-PAE hypervisor, use `gnumach-xen-nonpae` instead. -- Copy `hurd` into `/etc/xen`, edit it for fixing access to your hurd / and swap - -# GNU/Hurd system - -/!\ You need an already installed [[GNU/Hurd_system|hurd/running]]. - -If you have a free partition, you can fdisk to type 0x83, create a filesystem using: - - sudo mke2fs -b 4096 -I 128 -o hurd /dev/sda4 - -Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. - - -# /etc/xen/hurd configuration - -Here is a sample /etc/xen/hurd configuration - - kernel = "/boot/gnumach-xen-pae" - memory = 256 - disk = ['phy:sda4,hda,w'] - extra = "root=device:hd0" - vif = [ '' ] - ramdisk = "/boot/hurd-modules" - -Do not give more than 580MB memory (due to bootstrap limitations, it's not easy -to map more). - -Suggestions about [[networking_configuration]] are available. - -If you need stable MAC addresses, use a syntax like `vif = [ -'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. - - -# Running Hurd with Xen - -To run Hurd with Xen, use: - - xm create -c hurd - -and gnumach should get started. Proceed with native-install. - - export TERM=mach - ./native-install - -- If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. -- If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode. - - -# Building from sources - -If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. -Then look for "Ugly" in `kern/bootstrap.c`, how to generate `hurd-modules` is explained there, and you'll have to fix `EXT2FS_SIZE` and `LD_SO_SIZE` by hand. -Then use - - ./configure --enable-platform=xen - make - -The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. -/!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one! - -# `pv-grub` - -From Xen 4.0 on you can run the GNU Hurd directly using `pv-grub`, -without the need to [prepare a special bootstrap -image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an -initrd). - -Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use the following for instance: - - kernel = "/boot/pv-grub.gz" - memory = 256 - disk = ['phy:sda4,hda,w'] - extra = "(hd0,1)/boot/grub/menu.lst" - vif = [ '' ] - -extra is now the path to the grub config file. - -# Partitions - -You will need the following notation for the gnumach root= parameter: - -root=part:2:device:hd0 - -to access the second partition of hd0, for instance. - -You will also need to use the parted storeio module for the /dev entries, for instance: - -settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 - -# Miscellaneous - -[[Internals]]. - -[[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. - - -# Host-side Writeback Caching - -Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]], -*Host-side Writeback Caching*? - -IRC, freenode, #hurd, 2011-06-08 - - <braunr> youpi: does xen provide disk caching options ? - <youpi> through a blktap, probably - <braunr> ok diff --git a/microkernel/mach/gnumach/ports/xen/discussion.mdwn b/microkernel/mach/gnumach/ports/xen/discussion.mdwn deleted file mode 100644 index 2980e3b2..00000000 --- a/microkernel/mach/gnumach/ports/xen/discussion.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - -Stuff from <http://youpibouh.thefreecat.org/hurd-xen> should be merged into -these pages here. diff --git a/microkernel/mach/gnumach/ports/xen/internals.mdwn b/microkernel/mach/gnumach/ports/xen/internals.mdwn deleted file mode 100644 index eae9d9a8..00000000 --- a/microkernel/mach/gnumach/ports/xen/internals.mdwn +++ /dev/null @@ -1,14 +0,0 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -The port does use Xen's para-virtualized interface for device (ide, network, -etc.) access. - -[[Virtualization]]. diff --git a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn b/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn deleted file mode 100644 index 52e6db87..00000000 --- a/microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn +++ /dev/null @@ -1,105 +0,0 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!toc]] - -The Xen dom0 infrastructure provides for a bridged networking setup using shell -scripts to configure the bridging device properly and attach the domUs' virtual -interfaces to the bridge. However, we've [seen -problems](http://lists.gnu.org/archive/html/bug-hurd/2008-08/msg00023.html) -when using this approach, so to [solve these -issues](http://lists.gnu.org/archive/html/bug-hurd/2008-09/msg00071.html), -instead suggest the following configuration method (to achieve the same thing). - -This is for a Debian dom0. - -# */etc/network/interfaces* - -Comment out everything referencing your physical devices. Add this: - - auto br0 - iface br0 inet dhcp - bridge_ports regex (eth|vif).* noregex - -... or if you want to do the manual configuration dance: - - auto br0 - iface br0 inet static - bridge_ports regex (eth|vif).* noregex - address 192.168.10.60 - netmask 255.255.255.0 - [...] - -This needs a version of the `bridge-utils` package more recent than the current -Debian stable one ([[!debbug 405215]]). (It's trivial to rebuild the `dpkg` of, -e.g., the Debian testing one on Debian stable.) - -# */etc/xen/xend-config.sxp* - -Make sure that only `(network-script network-dummy)` and `(vif-script -vif-bridge)` are activated and all other `(network-script network-WHATEVER)`, -respective `(vif-script vif-WHATEVER)` are commented out. - - -# Sample configuration files on Debian Lenny - -## /etc/xen/hurd on dom0 - - kernel = "/boot/gnumach-xen" - memory = 256 - disk = ['phy:sda5,hda,w'] - extra = "root=device:hd0" - vif = [ 'mac=00:16:3e:00:00:00, bridge=br0' ] - ramdisk = "/boot/hurd-modules" - -/dev/sda5 is an extended partition. br0 is bridge interface on dom0. - -## /etc/xen/xend-config.sxp on dom0 - - (network-script 'network-bridge netdev=br0') - (dom0-min-mem 196) - (dom0-cpus 0) - (vncpasswd '') - -## /etc/network/interfaces on dom0 - - auto br0 - iface br0 inet static - address 192.168.1.211 - network 192.168.1.0 - netmask 255.255.255.0 - broadcast 192.168.1.255 - gateway 192.168.1.1 - bridge_ports eth1 - -eth1 is the interface that is connected to the Internet on the LAN: - -## Doing settrans on domU - - settrans -fgap /servers/socket/2 /hurd/pfinet -i eth0 -a 192.168.1.210 -g 192.168.1.1 -m 255.255.255.0 - -## /sbin/ifconfig on dom0 - - br0 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 - inet addr:192.168.1.211 Bcast:192.168.1.255 Mask:255.255.255.0 - inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link - UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 - RX packets:14187 errors:0 dropped:0 overruns:0 frame:0 - TX packets:9214 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:0 - RX bytes:936563 (914.6 KiB) TX bytes:746184 (728.6 KiB) - - eth1 Link encap:Ethernet HWaddr 00:19:d1:2e:06:33 - inet6 addr: fe80::219:d1ff:fe2e:633/64 Scope:Link - UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 - RX packets:34339 errors:0 dropped:0 overruns:0 frame:0 - TX packets:18526 errors:0 dropped:0 overruns:0 carrier:0 - collisions:0 txqueuelen:1000 - RX bytes:3019251 (2.8 MiB) TX bytes:1453672 (1.3 MiB) diff --git a/microkernel/mach/gnumach/projects.mdwn b/microkernel/mach/gnumach/projects.mdwn deleted file mode 100644 index f4ef192a..00000000 --- a/microkernel/mach/gnumach/projects.mdwn +++ /dev/null @@ -1,130 +0,0 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -This page is a place to keep track of ideas about things that may be improved -in GNU Mach, so that it'll evolve to 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 -*[[mailing lists/bug-hurd]]* stating what task you wish to work on, -so that no duplicate efforts end up. - -# Active Branches - - * `gnumach-1-branch` is the main branch. - - * `gnumach-1-branch-Xen-branch` is a branch created by Samuel Thibault for - working on a [[ports/Xen]] port. - - * `gnumach-1-branch-gdb-branch` is a branch created by Michael Casadevall for - working on [[GDB_stubs]]. - - -# Task List - - * [[Clean_up_the_code]] - - * [[Open Issues|tag/open_issue_gnumach]] - - * Update the core architecture and drivers - - * 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 - - * Migrating Threads (MT) could improve IPC performance and making easier - the work of the scheduler. For more information, check - <http://www.usenix.org/publications/library/proceedings/sf94/ford.html> - - * Improve the external pagers interface - - * Implement [[open_issues/performance/io_system/read-ahead]] (huge I/O - improvements expected). - - * 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 - - * 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 - - * 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 - - * 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 - - * Implement support for GDB debugging via serial line and/or network. - Maybe this can be done together with the host-specific work above. - - See [[GDB_stubs]]. - - * Make it run as a [[UNIX]]/Linux executable. - - * Neal: - - <neal> here's a fun project: port the mach interface to Linux - <neal> (e.g., via kernel modifications) - <neal> or, to posix/glibc - <neal> (mmap, some minimal ptrace, etc.) - - * From the [Hurd bits at - sourceforge.net](http://sourceforge.net/projects/hurd): - <http://hurd.cvs.sourceforge.net/hurd/gnumach-otop/>, started by John - Tobey. Last time touched in 2003. Status completely unknown. - - * [README](http://hurd.cvs.sourceforge.net/hurd/gnumach-otop/README?view=markup) - - -# Wish List - - * Interface for userspace non-critical drivers. - - * Sound Support - - * WLAN support (ipw2200) with WEP/WPA - - * ACPI support diff --git a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn deleted file mode 100644 index 2a9b4b60..00000000 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ /dev/null @@ -1,123 +0,0 @@ -[[!meta copyright="Copyright © 2005, 2006, 2007, 2008, 2010 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_gnumach]] - -# Restructure the tree in a sane way - -Merge `linux/src` and `linux/dev`. But only if using a sane RCS, so leave it -as-is for now. Also, a bunch of (header) files from there may probably be -discarded. - - -# Remove dead files from the GNU Mach source tree - -For *exported* files (via `make install`), the plan is to first stick some -`#error This file is scheduled for removal. Write to <bug-hurd@gnu.org> if you -have a reason to have it kept available.` into them, and then actually remove -them after some months. - -For some of the internal header files (containing function prototypes and the -like), it might actually be useful to use them. (And then get rid of a bunch -of `extern ...` statements in other files.) - -This following list was assembled by putting such a `#error ...` line into each -of the `gnumach-1-branch`'s header files (exported and internal; save the -`linux/` ones (only internal) for simplicity), and then trying to build GNU -Mach until this would succeed again (by removing offending `#error ...`s), and -afterwards using the set of exported files for building a cross toolchain -(again still removing offending `#error ...`s). A very crude and imprecise -method. - -So, additionally to the list given below, there may actually be a bunch of -further files (also exported ones) that serve no real value, but are being -`#include`d through one way or another. - -* [[!source_gnumach-1-branch ddb/db_expr.h]] - - Currently used, but copyright violation? Rewrite? - -* [[!source_gnumach-1-branch ddb/db_print.h]] - - Copyright violation? Currently unused, but could be used in principle (or - be rewritten, to avoid the copyright oddity). - -* [[!source_gnumach-1-branch ddb/tr.h]] - - Copyright violation. Unused. Remove. - -* [[!source_gnumach-1-branch device/dev_master.h]] - - Might be usable for SMP? Remove otherwise. - -* [[!source_gnumach-1-branch i386/i386/kttd_machdep.h]] - -* [[!source_gnumach-1-branch i386/i386/sched_param.h]] - -* [[!source_gnumach-1-branch i386/include/mach/i386/cthreads.h]] - - Was probably once exported, but is no longer. - -* [[!source_gnumach-1-branch i386/include/mach/i386/ioccom.h]] - - Exported. - -* [[!source_gnumach-1-branch include/device/audio_status.h]] - - Exported. - -* [[!source_gnumach-1-branch include/device/tape_status.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/alert.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/boot.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/macro_help.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/multiboot.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/profil.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/profilparam.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach/exec/a.out.h]] - - Exported. - -* [[!source_gnumach-1-branch include/mach_debug/pc_info.h]] - - Currently not exported, but was probably once meant to be. - -* [[!source_gnumach-1-branch kern/act.h]] - -* [[!source_gnumach-1-branch kern/refcount.h]] - -* [[!source_gnumach-1-branch kern/shuttle.h]] - - -# Remove dead functions, variables, etc. from source files - - -# Rewrite ugly code diff --git a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn b/microkernel/mach/gnumach/projects/gdb_stubs.mdwn deleted file mode 100644 index 064da7bf..00000000 --- a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2010 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_gnumach open_issue_gdb]] - - * <http://lists.gnu.org/archive/html/bug-hurd/2008-04/msg00103.html> - - * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) - -This may be another follow-up project: [*Linux Kernel GDB tracepoint -module*](http://thread.gmane.org/gmane.comp.gdb.devel/29369), Hui Zhu, -2010-10-09. diff --git a/microkernel/mach/gnumach/reference_manual.mdwn b/microkernel/mach/gnumach/reference_manual.mdwn deleted file mode 100644 index 95d11517..00000000 --- a/microkernel/mach/gnumach/reference_manual.mdwn +++ /dev/null @@ -1,26 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008 -Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -*The GNU Mach Reference Manual* documents the architecture, the usage and the -programming of the GNU Mach microkernel. At the moment, the manual documents -the interface completely, but is not very useful as a tutorial or introduction -into the Mach architecture. - - * [HTML version](http://www.gnu.org/software/hurd/gnumach-doc/index.html) - for browsing online, - * [PostScript - version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps) [around - 900KiB], - * [gzipped PostScript - version](http://www.gnu.org/software/hurd/gnumach-doc/mach.ps.gz) - [around 300KiB], - * [PDF version](http://www.gnu.org/software/hurd/gnumach-doc/mach.pdf) - [around 700KiB]. diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn deleted file mode 100644 index 5a3608cd..00000000 --- a/microkernel/mach/history.mdwn +++ /dev/null @@ -1,60 +0,0 @@ -# <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 this -list of [[gnumach/projects]]. - -# <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 deleted file mode 100644 index 1bb44b59..00000000 --- a/microkernel/mach/ipc.mdwn +++ /dev/null @@ -1,21 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Read about the [[general concept of *inter-process communication* (IPC)|/ipc]]. - -On Mach, an IPC is done by invoking a [[port]]. - -The two fundamental operations, to *send* and *receive* [[message]]s, are used -to implement a [[RPC]] system. - -[[Sequence_numbering]]. - -[The Unofficial GNU Mach IPC beginner's guide](http://www.nongnu.org/hurdextras/ipc_guide/ipc_guide.html) diff --git a/microkernel/mach/ipc/sequence_numbering.mdwn b/microkernel/mach/ipc/sequence_numbering.mdwn deleted file mode 100644 index eb94d662..00000000 --- a/microkernel/mach/ipc/sequence_numbering.mdwn +++ /dev/null @@ -1,19 +0,0 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Mach's [[IPC]] mechanism allows for getting access to a message's sequence -number. - -This can be used for serializing requests in a multithreaded environment. - -* [GNU Mach Reference Manual: 4.2.6 Message - Receive](http://www.gnu.org/software/hurd/gnumach-doc/Message-Receive.html) -* [GNU Mach Reference Manual: 4.3.6 Receive - Rights](http://www.gnu.org/software/hurd/gnumach-doc/Receive-Rights.html) diff --git a/microkernel/mach/memory_object.mdwn b/microkernel/mach/memory_object.mdwn deleted file mode 100644 index f32fe778..00000000 --- a/microkernel/mach/memory_object.mdwn +++ /dev/null @@ -1,33 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Mach's [[virtual_memory]] subsystem uses *memory objects* for supplying the -content of regions of virtual memory in an [[virtual_address_space]]. - -All of these objects are managed by *memory manager*s, that are also called -*pager*s. These can be implemented as user-space processes. - -Both the memory objects, and their managers are kernel objects, and are -accessed by [[port]]s. - -A system's 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|external_pager_mechanism]] by the aforementioned memory managers. 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, -in contrast to most of the others. The default memory manager is needed -because the microkernel can't wait infinitely for someone else to free the -memory cache: it just calls the next memory manager hoping it to succeed. - -Read about [[GNU Mach's memory management|gnumach/memory_management]]. diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn deleted file mode 100644 index 907f859a..00000000 --- a/microkernel/mach/memory_object/discussion.mdwn +++ /dev/null @@ -1,74 +0,0 @@ -[[!meta copyright="Copyright © 2011, 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation open_issue_gnumach]] - -[[!toc]] - - -# IRC, freenode, #hurd, 2011-08-05 - - < neal> braunr: For instance, memory objects are great as they allow you to - specify the mapping policy in user space. - < neal> braunr: But, the policy for determining the eviction order is - realized by Mach - < neal> braunr: And user-space has no control - < braunr> are you referring to the page cache lru approximation and stuff - like resource containers ? - < neal> I'm not sure what you mean by page cache lru appoximateion - < braunr> the kernel eviction policy :) - < neal> that's an implementation detail - - -# IRC, freenode, #hurd, 2011-09-05 - - <braunr> mach isn't a true modern microkernel, it handles a lot of - resources, such as high level virtual memory and cpu time - <braunr> for example, the page replacement mechanism can't be implemented - outside the kernel - <braunr> yet, it provides nothing to userspace server to easily allocate - resources on behalf of clients - <braunr> so, when a thread calls an RPC, the cpu time used to run that RPC - is accounted on the server task - <braunr> the hurd uses lots of external memory managers - -[[external_pager_mechanism]]. - - <braunr> but they can't decide how to interact with the page cache - <braunr> the kernel handles the page cache, and initiates the requests to - the pagers - <cjuner> braunr, why can't they decide that? - <braunr> because it's implemented in the kernel - <braunr> and there is nothing provided by mach to do that some other way - <slpz_> braunr: you probably already know this, but the problem with client - requests being accounted on behalf the server, is fixed in Mach with - Migrating Threads - -[[open_issues/mach_migrating_threads]]. - - <braunr> slpz_: migrating threads only fix the issue for the resources - managed by mach, not the external servers - <braunr> slpz_: but it's a (imo necessary) step to completely solve the - issue - <braunr> in addition to being a great feature for performance (lighter - context switchers, less state to track) - <braunr> it also helps priority inversion problems - <slpz_> braunr: I was referring just to cpu-time, but I agree with you an - interface change is needed for external pagers - <braunr> slpz_: servers in general, not necessarily pagers - <slpz_> as a way to mitigate the effect of Mach paging out to external - pagers, the folks at OSF implemented an "advisory pageout", so servers - are "warned" that they should start paging out, and can decide which - pages are going to be flushed by themselves - -[[open_issues/resource_management_problems]]. - - -# [[open_issues/memory_object_model_vs_block-level_cache]] diff --git a/microkernel/mach/message.mdwn b/microkernel/mach/message.mdwn deleted file mode 100644 index ba47671e..00000000 --- a/microkernel/mach/message.mdwn +++ /dev/null @@ -1,31 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -*Messages* are collections of typed data, with a defined layout. - -They are used for [[IPC]], and are sent to and received from [[port]]s. - -These messages are not only opaque data. They can also contain [[port -rights|port]] to be passed to another [[task]]. Port rights are either -*copied* or *moved*. Notice that port receive right must be moved but not -copied because there can't be more than one task that holds the receive right -to a port. The receiving task creates new local port name to the port rights -it received. - -Some data in the message can be *out-of-line data*. In the message, these are -*references* to memory regions ([[memory_object]]s) that are *virtually -copied*. When the message is received in a task, these virtual copies become -part of the task by mapping them into the receiver's [[virtual_address_space]]. -Another key concept that is applied is using *copy-on-write*, which means that -data is not copied immediately, but only when it is changed. This is primarily -used to send large blocks of data efficiently, as it is too expensive to store -them in the kernel address space: extra copied need only be made at the moment -that the memory regions begin to diverge, by threads modifying them. diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn deleted file mode 100644 index 331b3bf4..00000000 --- a/microkernel/mach/mig.mdwn +++ /dev/null @@ -1,35 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2002, 2003, 2006, 2007, 2008, 2010 Free -Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -The *Mach Interface Generator* (*MIG*) is an [[IDL]] compiler. Based on an -interface definition, it creates stub code to [[invoke]] object methods and to -demultiplex incoming messages. These stub functions conveniently hide the -details of Mach's [[IPC]] and [[port]] machinery and make it easy to implement -and use Mach [[interface]]s as [[remote procedure calls (RPC)|rpc]]: by using -the stub functions, the client programs can call remote procedures more or less -like any other C function. - -These functions encode arguments into [[message]]s' format (*marshalling*), -wait for a result on a newly created [[reply port|port]], decode return -arguments from the reply message (*demarshalling*, or *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. - - - * [[Documentation]] - - -# Implementations - - * [[GNU_MIG]] diff --git a/microkernel/mach/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn deleted file mode 100644 index 7d4f1eca..00000000 --- a/microkernel/mach/mig/documentation.mdwn +++ /dev/null @@ -1,84 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2005, 2007, 2008, 2009, 2010 Free -Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -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 inter-process 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 -](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/machuse.ps), -[Doc](http://www.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](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig_example) -for this tutorial. - -Slides to Rich Drave's talk on MIG, on November 21, 1991: -[PostScript](http://www.cs.cmu.edu//afs/cs/project/mach/public/doc/unpublished/internals_slides/Mig/root.ps), -[TeX](http://www.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 inter-process communication interfaces. MIG is an interim -implementation of a subset of the Matchmaker language that generates C and C++ -remote procedure call interfaces for inter-process communication between Mach -tasks." - -Richard P. Draves, Michael B. Jones, Mary R. Thompson, *MIG - THE MACH -INTERFACE GENERATOR*. -[ps](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps), -[doc](http://www.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). "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." - - -# Further Relevant Documentation - - * The [[GNU_Mach_Reference_Manual|gnumach/reference_manual]], espacially - [Chapter 4, Inter Process - Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html). - - * OSF's [Server Writer's Guide (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_writer.ps) - [Server Writer's Guide (pdf)](http://shakthimaan.com/downloads/hurd/server_writer.pdf) - - * OSF's [Server Writer's Interfaces (ps)](http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/server_interface.ps) - [Server Writer's Interfaces (pdf)](http://shakthimaan.com/downloads/hurd/server_interface.pdf) - - * Flags: - - * [[dealloc_and_dealloc[]|dealloc]] - * [[ServerCopy]] - - * MIG *in action*: [[hurd/io_path]]. diff --git a/microkernel/mach/mig/documentation/dealloc.mdwn b/microkernel/mach/mig/documentation/dealloc.mdwn deleted file mode 100644 index b627b532..00000000 --- a/microkernel/mach/mig/documentation/dealloc.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -The [[GNU_Mach_Reference_Manual|gnumach/reference_manual]] describes the -`dealloc` flag in [Chapter 4.2.4, -Memory](http://www.gnu.org/software/hurd/gnumach-doc/Memory.html). - -What exactly is `dealloc[]` (`hurd/fs.defs:dir_readdir`)? diff --git a/microkernel/mach/mig/documentation/servercopy.mdwn b/microkernel/mach/mig/documentation/servercopy.mdwn deleted file mode 100644 index 8abf9b07..00000000 --- a/microkernel/mach/mig/documentation/servercopy.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -For IN args. If set it... - - * removes the `__mig_deallocate` for OOL IN data, which is usually done after - the implementation has been called; - - * adds a `boolean_t NAMESCopy` for the IN arg `NAME` to indicate whether the - data will persist nevertheless (OOL case) or has to be copied by the - implementation (inline case). - -Cf., [[translator/exec]] server, `exec.defs`. - -I.e., the IN args' memory region (OOL case) persists after the implementation -has returned. diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn deleted file mode 100644 index 0de1bd67..00000000 --- a/microkernel/mach/mig/gnu_mig.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -[[!meta copyright="Copyright © 2001, 2006, 2008, 2009, 2010 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -GNU MIG is the GNU distribution of the -[[Mach_3.0_interface_generator_*MIG*|mig]], as maintained by the GNU Hurd -developers for the GNU project. - -You need this tool to compile the GNU Mach and GNU Hurd distributions, and to -compile the GNU C library for the Hurd. Also, you will need it for other -software in the GNU system that uses Mach-based -[[inter-process_communication|ipc]]. - -GNU MIG is fully compatible with [[OSF_MIG|mig]]. - -Like its predecessor, it can only generate C code, that has to be compiled and -linked to client and server programs respectively ([[!taglink -open_issue_mig]]). - - * [[Building]] - building (and obtaining) GNU MIG - * [[Open Issues|tag/open_issue_mig]] diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn deleted file mode 100644 index e7d3c150..00000000 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ /dev/null @@ -1,103 +0,0 @@ -[[!meta copyright="Copyright © 2006, 2007, 2008, 2011 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -# <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' -RCS](http://git.savannah.gnu.org/cgit/hurd/): - - $ git clone http://git.savannah.gnu.org/cgit/hurd/mig.git/ - -... or (if you are working on a Debian system) get the sources that are used for the -[current Debian mig package](http://packages.debian.net/source/unstable/mig): - - $ apt-get source mig - -Please see the Debian [[hurd/running/debian/FAQ]] before using _apt-get source_. - -The unpacked source tree is around 1 MiB, and the build tree also is around 1 MiB. - -## <a name="_on_Debian_systems"> On Debian Systems: </a> - -### <a name="Preparing_for_the_Build"> Preparing for the Build </a> - -Building MIG requires the *build-essential* and *fakeroot* packages, -and some additional dependencies specified by the mig source package: - - # apt-get install build-essential fakeroot - # apt-get build-dep mig - -### <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: - - $ cd mig-X.X.X.XX - -Start the build process: - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -This will create a _.deb_ package in the parent directory, -which you can then install on your system. - -## <a name="_on_non_Debian_systems"> On non-Debian Systems: </a> - -### <a name="Preparing_for_the_Build"> Preparing for the Build </a> - -Building the Mach Interface Generator requires a C compiler, a standard 32 bit -C library (with corresponding header files), your favourite flavor of awk -(gawk), yacc (bison), lex (flex) and make. - -Additionally, you need to have GNU Mach's header files installed. See -[[building GNU Mach|mach/gnumach/building]] about how to do that, then come back here. - -### <a name="Building_and_Installing"> Building and Installing </a> - -First, generate the configuration files: - - $ cd mig - $ autoreconf --install - -The Mach Interface Generator has to be built in a separate build directory: - - $ mkdir build - $ cd build - -Find the base directory where you installed GNU Mach's header files and where -you now intend to install the Mach Interface Generator (e.g. _~/gnu_), and run -configure: - - $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" - -If you are building on a 64 bit machine, you need to add a --host option: - - $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-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/gnu_mig/building/discussion.mdwn b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn deleted file mode 100644 index d7636158..00000000 --- a/microkernel/mach/mig/gnu_mig/building/discussion.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -# Non-cross-compiling - -[[!tag open_issue_mig]] - -[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] - diff --git a/microkernel/mach/pmap.mdwn b/microkernel/mach/pmap.mdwn deleted file mode 100644 index 6910bfd3..00000000 --- a/microkernel/mach/pmap.mdwn +++ /dev/null @@ -1,74 +0,0 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation open_issue_gnumach]] - - -# IRC, freenode, #hurd, 2012-02-01 - - <sekon> on Hurd what is the difference between kernel memory object and - pmap module ?? - <sekon> pmap is heap/libraries table for each thread while kernel memory - object refers to arbitary blobs of data ?? - <braunr> sekon: pmap is the low level memory mapping module - <braunr> i.e. it programs the mmu - <braunr> and these aren't hurd-specific, they are mach modules - <sekon> braunr: so kernel memonry objects consists of a bunch of pmaps ?? - <braunr> sekon: memory objects can be various things, be specific please - <braunr> (they're certainly not a bunch of pmaps though, no) - <braunr> there is one pmap per vm_map, and there is one vm_map per task - <braunr> and there is no need for double question marks, is ther ?? - <sekon> lol then is kernel memory object , please excuse the metaphor - something like a base class for pmap - <braunr> i don't know what a "kernel memory object" is, be specific please, - again - <sekon> braunr: - http://courses.cs.vt.edu/~cs5204/fall05-gback/presentations/MachOS_Rajesh.ppt - <sekon> goto page titled External Memory Management (EMM) on page 15 - <sekon> Kernel memory object shows up - <braunr> you know there are other formats for this document - <sekon> nope .. i did not know that - <sekon> in page 17 pmamp shows up - <braunr> "the problems of external memory management" ? - <sekon> braunr: the paper i am also reading is called x15mach_thesis - <braunr> ah, that's mine - * sekon bows - <sekon> :) - <braunr> ok i see page 17 - <sekon> so please good sir explain the relationship between kernel memory - object and pmap - <sekon> (if any) - <sekon> braunr: there is no mention of kernel memory object - <braunr> again, i don't see any reference or definition of "kernel memory - object" - <sekon> but your paper says - <sekon> that when page faults occur - <sekon> the kernel contact the manager for a kernel reference object - <sekon> *memory - <braunr> where ? - <sekon> in section 2.1.3 (unless i read it wrong) - <sekon> no just a sec - <sekon> 2.1.5 - <braunr> i never used the expression "kernel memory object" there :p - <braunr> anyway, you're referring simple to memory objects as seen by - userspace pagers - <braunr> a memory object is a data container - <braunr> usually, it's a file - <braunr> but it can be anything - <braunr> the pager is the task that provides its content and implements the - object methods - <braunr> as for the relation between them and the pmap module, it's a - distant one - <braunr> i'll explain it with an example - <braunr> page fault -> request content of memory object at a given offset - with given length from pager -> ask pmap to establish the mapping in the - mmu - <sekon> braunr: thank you ver much - <sekon> *very diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn deleted file mode 100644 index 26b55456..00000000 --- a/microkernel/mach/port.mdwn +++ /dev/null @@ -1,89 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[Mach]] *port*s are [[capabilities|capability]], and are also essentially -similar to [[UNIX]] pipes. They are unforgeable communication channels, -implemented by kernel queues. - -Each port has associated with it one *receive right* and one or more *send -right*s and *send-once right*s. That is, there is one receiver and one or more -senders -- a unidirectional communication channel. Only with the corresponding -port right, access to a port is possible; this is enforced by Mach. - -The kernel queue can hold a number of [[message]]s. Once the queue is full, -the send blocks until there is space to enqueue the message (this is -interruptible via a timeout mechanism). - -A receive right [[designates|designation]] 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. - -Ports are automatically destroyed when there is no associated port right to -them. - -Mach knows what port rights belong to each task, but [[thread]]s that running -in the context of a task refer to ports by means of send and receive rights -that are named using local *port names*. These port names are plain integers, -like [[UNIX file descriptors|unix/file_descriptor]]. Only these local names -can be used by [[thread]]s for invoking operations on ports, threads do not -deal with port rights directly. - -For that, each task has associated with it a *port address space*, or *port -name space*. All ports are addressed via this table. Each task thus has its -own private [[naming_context]] for port rights. - -So, the picture is that after obtaining a port send right, the client uses a -port name to send [[message]]s to the port, or exactly one message if it's a -send-once right. These messages are (probably) queued and when the server task -tries to receive messages by having a [[thread]] use its port receive right, it -gets the message(s). This is called [[IPC]]. - -Port rights themselves can be [[delegate]]d in a [[message]], too. When the -receiver dequeues the message, the right is made available to it. - -The delivery of [[message]]s 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. Of course, there can be -intermediate messages that are sent by other threads. - -Ports are objects that are implemented by the [[kernel]], and they are -kernel-protected resources: they are unforgeable, and there is no way for a -[[task]] to do anything with a port unless it have corresponding port right. - -Due to this, ports are globally unique. This makes them ideal for constituting -system-wide *object references*. (Fruther reading: -{{$capability#wikipedia_object-capability_model}}.) For example, the [[RPC]] -system as used by the GNU Hurd works by invoking *methods* on such object -references. The available methods are defined in [[hurd/interface]] files, and -are processes by the [[MIG]] tool. - -Invoking an operation on a port does not transfer the current execution control -to the receiver, but instead is an asynchronous operation. For this, and -especially in a [[RPC]] system, the sender may include a *reply port* using a -send-once right, and synchronize (block) on that one. - - -# Port Set - -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. These port sets look like port receive rights, but -cannot be passed to other tasks, and there are additional operations for adding -and removing port receive rights. - -When a server process' thread receives from a port set, it dequeues exactly one -message from any of the ports that has a message available in its queue. - -This concept of port sets is also the facility that makes convenient -implementation of [[UNIX]]'s `select` [[system_call]] possible. diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn deleted file mode 100644 index 422e0441..00000000 --- a/microkernel/mach/rpc.mdwn +++ /dev/null @@ -1,28 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011 Free Software -Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Read about the [[general concept of a *remote procedure call* (RPC)|/rpc]]. - -Uses Mach's [[IPC]] [[mechanism]]. - -The [[port]] abstraction allows RPCs to be executed on another computer -transparently. This can be implemented with user [[task]]s, but there is an -implementation in the kernel possible, too, which is called *NORMA*, but is not -avilable in [[GNU Mach|gnumach]]. - -The RPC stub code generated by [[MIG]]. - - -# Tracing - - * [[hurd/debugging/rpctrace]] - - * [[open_issues/librpci]] diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn deleted file mode 100644 index 00e4a012..00000000 --- a/microkernel/mach/rpc/discussion.mdwn +++ /dev/null @@ -1,117 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_documentation]] - - -# IRC, freenode, #hurd, 2011-06-11 - - <antrik> I don't think we have a precendence case of Mach initiating RPCs - to userspace tasks - <braunr> well mach regularly sends RPCs to external pagers - <antrik> hm, right - <antrik> anyways, the ds_ in device.defs is for use *inside* Mach, not for - the userspace interface - <braunr> what makes you think so ? - <antrik> several things - <antrik> not least the fact that without zhengda's modifications, the - device handling never calls out to userspace for all I know - <braunr> hm, it does - <braunr> for async I/O - <braunr> when the kernel has finished its I/O, it calls - ds_device_read_reply/ds_device_write_reply - <antrik> I see - <antrik> I never quite understood the _reply stuff - <braunr> although i wonder how mig is supposed to forge those names - <antrik> braunr: it isn't - <antrik> braunr: there is a separate device_reply.defs - <antrik> braunr: and it sets a *userprefix* of ds_ - <antrik> rather than a serverprefix - <braunr> i saw, yes - <braunr> ah right - <antrik> so ds still refers to the in-Mach device server, not anything - userspace - <braunr> so this is where the patch is supposed to introduce the - device_intr_notify RPC - <antrik> or at least that's my understanding... - <braunr> no, it doesn't refer to in-mach servers - <braunr> it really forges the right rpcs to be called by mach - <antrik> the definition of "RPC" is rather unclear here - <braunr> why ? - <braunr> mach has its own mach_msg() call for kernel-to-user messaging - <antrik> yes, but this is used only to send the reply message for the RPC - earlier initiated by userspace AIUI - <antrik> it doesn't look like there is any special RPC for async I/O - <braunr> yes, because this is the only use case they had - <braunr> hence the name "reply" - <braunr> intr_notify isn't a reply, but it uses the same mechanism - <braunr> these are declared as simpleroutine - <antrik> sure. but the fact that it isn't a reply message, but rather - initiates a new RPC, changes things from MiG point of view I believe - <antrik> right, as there is no reply to the reply :-) - <braunr> :) - <braunr> a simpleroutine is how to turn an rpc into a simple ipc - <antrik> I know - <antrik> so in _reply, we pretend that the reply is actually a new RPC, - with server and client roles reversed, and no reply - <antrik> (this is actually rather kludgy... apparently MIG has no real - notion of async replies) - <braunr> i don't understand what you mean - <braunr> simpleroutine is the explicit solution for async replies - <braunr> as stated in - http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps - <braunr> it's not a new rpc with roles reversed - <braunr> it's not a reply either - <antrik> it might be an explicit solution for that, but it still seems - kludgy :-) - <braunr> i don't see why :/ - <braunr> would you have expected something like an option to create both - sync and async versions ? - <antrik> because it requires an extra .defs file - <antrik> yes - <braunr> ok - <braunr> well this seems cumbersome to me :) - <braunr> i prefer the simpleroutine approach - <braunr> but i agree this seems odd since mach has a high level ipc api - <antrik> anyways, my point is that the ds_ in device_reply.defs still - refers to the Mach side of things - <braunr> npnth: which package fails to build ? - <antrik> though a userspace process that actually handles the replies in an - async fashion will of course need some kind of device server too, just - like the DDE stuff... - <antrik> though naming it ds_ is confusing IMHO, because of the name clash - with the device server in Mach - <braunr> hm again, i fail to see why - <braunr> ds_ just means device_server - <braunr> and as most things in mach, it can be in kernel or not - <braunr> i mean, this is an interface prefix, i don't refer to an actual - single instance of a "device server" out there - <antrik> oh, right... DDE implements the Mach device protocol, so it *does* - do the ds_ part... but that makes the interrupt notification stuff even - more confusing - <braunr> hm - <braunr> because it provides a ds_device_intr_notify() which will never be - used, just to completely implement the interface ? - <antrik> yeah, that's what I suspect... - <braunr> sounds likely - <antrik> the device interface actually has two parts: one for "generic" - RPCs on the master device port, and one for device-specific RPCs. DDE - implements the latter, and uses the former... - <antrik> they live in separate places though I think: the individual device - RPCs are implemented in libmachdev, while the intr_ stuff is used in - libddekit probably - <braunr> it would be hairy to build otherwise - <antrik> so we *really* need to know what component npnth gets the error - with - <antrik> braunr: nah, not really. that's why we always have a separate - prefix for the server routines in Hurd RPCs - <braunr> right, i really need to read about mig again - <antrik> it's pretty normal for a translator to both implement and use an - interface diff --git a/microkernel/mach/task.mdwn b/microkernel/mach/task.mdwn deleted file mode 100644 index c03c6a14..00000000 --- a/microkernel/mach/task.mdwn +++ /dev/null @@ -1,23 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -A Mach *task* is a collection of resources, a [[virtual_address_space]], and a -[[port name space|port]]. They depend on [[thread]]s for executing program -code: a task alone has no means to do so. - -Switching from one task to another one involves doing a *context switch*, which -is usually not a cheap operation, as it involves switching the hardware's idea -of the memory layout ([[virtual_address_space]]), amongst others. - -Mach tasks are distinct from [[UNIX processes|unix/process]] in that they -provide less facilities. In processes, there are [[unix/signal]]s, process / -group / session IDs, [[unix/file_descriptor]]s and many other things. Tasks -are used for resource allocation and sharing; they are *resource container*s. diff --git a/microkernel/mach/thread.mdwn b/microkernel/mach/thread.mdwn deleted file mode 100644 index e27bb117..00000000 --- a/microkernel/mach/thread.mdwn +++ /dev/null @@ -1,37 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -A Mach *thread* belongs to exactly one [[task]], and is the means of execution. -The task supplies the resources. - -Mach threads are implemented inside the [[kernel]], as opposed to other -systems' user-level thread packages. - -A thread (theoretically) runs concurrently with all the other threads of a -system. If the system provides several processors, they can be used for -simultaneously running either several threads of the same task, or several -threads of different tasks. <!-- This is called SMP; the processors use -*shared memory*. --> [[!tag open_issue_documentation]] <!-- This needs a new -page, also covering Mach's `processor_set`s, and non-SMP, but still -multiprocessor systems. --> (But this is currently not support in [[GNU -Mach|gnumach]].) - -It is easy for the kernel to switch execution from one thread to another one -inside the same task: essentially, it only involves exchanging a few processor -registers' state. - -Threads have scheduling parameters and maintain various statistics about -themselves. - -On GNU/Hurd, APIs for Mach threads and thereabouts are provided by the -[[hurd/libthreads]] (cthreads), and [[libpthread]] (POSIX Threads) packages. - -A task backing a thread is the basis for a [[UNIX process|unix/process]]. diff --git a/microkernel/mach/virtual_address_space.mdwn b/microkernel/mach/virtual_address_space.mdwn deleted file mode 100644 index 97bc5f6b..00000000 --- a/microkernel/mach/virtual_address_space.mdwn +++ /dev/null @@ -1,36 +0,0 @@ -[[!meta copyright="Copyright © 2002, 2003, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -*Virtual address space*s in Mach define the valid virtual addresses that can be -used by [[thread]]s under execution 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 (for example, in the -Mach API) we name it by the task it belongs to. - -These address spaces are 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. Page manipulation is optimized to help moving large blocks of data -from one address space to another, for example when one thread provides data to -another thread -- *client / server* technology. - -Memory ranges of pages that can be controlled as a whole are called -*[[memory_object]]*s. - -*Wired pages* are those that cannot be [[paged out|external_pager_mechanism]]. -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|external_pager_mechanism]] that use disks as backing store. diff --git a/microkernel/research.mdwn b/microkernel/research.mdwn deleted file mode 100644 index 4eefe602..00000000 --- a/microkernel/research.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -## <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) diff --git a/microkernel/viengoos.mdwn b/microkernel/viengoos.mdwn deleted file mode 100644 index 66c6ff36..00000000 --- a/microkernel/viengoos.mdwn +++ /dev/null @@ -1,45 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -*Viengoos* is a research kernel, designed and written by Neal Walfield. - -As of late 2009, the project is on hold, due to time constraints. - -Viengoos is not really meant to be a successor to [[Mach]]. It is highly -experimental; some of the techniques it employs, in particular, those related -to [[memory_management]] and [[IPC]], are unproven. These were motivated by -[[shortcomings_in_Mach|hurd/critique]] as well as current operating systems. A -research system is unlikely the best base for a product. A better approach is -to view Viengoos as an experimental platform whose goal is to explore solutions -to some of the [[issues_uncovered_by_the_Hurd|challenges]]. Knowledge gained -can then be integrated into something like [[Mach]]. - -The source can be downloaded from the *viengoos.git* repository, cf. -<http://git.savannah.gnu.org/gitweb/?p=hurd/viengoos.git>. You can -check it out using, for example: - - git clone git://git.sv.gnu.org/hurd/viengoos.git - -Then update to viengoos-on-bare-metal - - cd viengoos - git checkout -b viengoos-on-bare-metal origin/viengoos-on-bare-metal - -viengoos-on-bare-metal is the current development focus. - -Discussion should be held on the [[mailing lists/l4-hurd]] mailing list. - - * [[Building]] - * Running - * [[QEMU]] - * [[Hardware]] - * [[Documentation]] - * [[Projects]] diff --git a/microkernel/viengoos/building.mdwn b/microkernel/viengoos/building.mdwn deleted file mode 100644 index 45111c35..00000000 --- a/microkernel/viengoos/building.mdwn +++ /dev/null @@ -1,100 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Check out Viengoos and switch to the viengoos-on-bare-metal branch -(all development is currently done on this branch and it will -eventually be merged into the master branch): - - $ git clone git://git.savannah.gnu.org/hurd/viengoos.git - $ cd viengoos - $ git checkout -b viengoos-on-bare-metal origin/viengoos-on-bare-metal - -Generate the autoconf environment (note that --force is not specified -as we have our own version of config.guess and config.sub): - - $ autoreconf -i - -Configure a build directory: - - $ mkdir build - $ cd build - $ ../configure --host=x86_64-pc-viengoos-gnu --with-newlib - -Now, build Viengoos. Running make the first time will automatically -fetch binutils and gcc from the Internet and build a cross compiler. -Running make again will build the Viengoos proper. Again, the build -process with fetch several tarballs including Newlib, the Boehm GC and -Sqlite. - - $ make - ... - The cross compiler is now set-up. Re-run `make' and proceed as usual. - make[2]: Leaving directory `.../viengoos/build' - make[1]: Leaving directory `.../viengoos/build' - $ make - -# Booting Using QEMU - -To boot Viengoos, use Grub 2. You cannot use Grub Legacy: Viengoos is -an ELF64 executable, which Grub Legacy does not support. - -First, check out Grub 2 from svn: - - $ svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 - $ cd grub2 - -Before building Grub 2, you should apply the following patch, which -makes it easy to tell Grub to load a specific grub.cfg at start up -([details](http://lists.gnu.org/archive/html/grub-devel/2009-01/msg00099.html)). - - $ wget http://www.gnu.org/software/hurd/microkernel/viengoos/grub2-config.diff -O /dev/stdout | patch -p0 - -Next, build Grub 2: - - $ ./autogen.sh - $ mkdir build - $ cd build - $ ../configure --prefix=`pwd`/../install - $ make && make install - -Create the boot disk: - - $ cd ../install - $ bin/grub-mkrescue boot.img --configfile="(hd0,1)/grub.cfg" --image-type=floppy --modules='help reboot serial multiboot pc configfile normal boot fat' - -Now, create /viengoos and link viengoos and hieronymus into that -directory: - - $ mkdir /viengoos - $ cd /viengoos - $ ln -s ~/viengoos/build/viengoos/viengoos.stripped viengoos - $ ln -s ~/viengoos/build/hieronymus/hieronymus.stripped hieronymus - -Also, create a grub.cfg file in /viengoos/grub.cfg: - - set timeout=1 - set default=0 - set root=hd0,1 - - menuentry "Viengoos" { - multiboot /viengoos -D 3 -o serial - module /hieronymus - } - -NB: If you edit grub.cfg and a backup file called grub.cfg~ is -created, qemu will use grub.cfg~ instead of grub.cfg! Thus, after -editing grub.cfg, be sure to delete any grub.cfg~ file! - -Finally, boot! - - $ qemu-system-x86_64 -serial stdio -fda ~/grub2/install/boot.img -hda fat:/viengoos -boot a - -By default, Hieronymus is configured to load ruth, a test suite. Ruth -can take a long time to complete. diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn deleted file mode 100644 index edcc79a7..00000000 --- a/microkernel/viengoos/documentation.mdwn +++ /dev/null @@ -1,62 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -The most up-to-date documentation is in the source code itself, see in -particular the header files in the hurd directory. - -There is a started but as-of-yet incomplete manual in the doc -directory, which documents the Viengoos API and the Hurd API. A -version of that is available [[here|reference-guide.pdf]]. It is -not, however, automatically regenerated, and thus may not be up to -date. - - -# Academic Papers - - * [Viengoos: A Framework for Stakeholder-Directed Resource - Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf). - By Neal H. Walfield. Submitted to EuroSys 2009. - - General-purpose operating systems not only fail to provide adaptive - applications the information they need to intelligently adapt, but - also schedule resources in such a way that were applications to - aggressively adapt, resources would be inappropriately scheduled. The - problem is that these systems use demand as the primary indicator of - utility, which is a poor indicator of utility for adaptive - applications. - - We present a resource management framework appropriate for traditional - as well as adaptive applications. The primary difference from current - schedulers is the use of stakeholder preferences in addition to - demand. We also show how to revoke memory, compute the amount of - memory available to each principal, and account shared - memory. Finally, we introduce a prototype system, Viengoos, and - present some benchmarks that demonstrate that it can efficiently - support multiple aggressively adaptive applications simultaneously. - - * [Improving Usability via Access Decomposition and Policy - Refinement](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). - By Neal H. Walfield and Marcus Brinkmann. Technical report - (submitted to HotOS 2007). - - Commodity operating systems fail to meet the security, resource - management and integration expectations of users. We propose a unified - solution based on a capability framework as it supports fine grained - objects, straightforward access propagation and virtualizable - interfaces and explore how to improve resource use via access - decomposition and policy refinement with minimum interposition. We - argue that only a small static number of scheduling policies are - needed in practice and advocate hierarchical policy specification and - central realization. - - -# Miscellaneous - - * [[IRC_2012-02-23]] diff --git a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn deleted file mode 100644 index a3229be9..00000000 --- a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn +++ /dev/null @@ -1,159 +0,0 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!meta title="IRC, freenode, #hurd, 2012-02-23"]] - -[[!tag open_issue_documentation open_issue_viengoos]] - - <braunr> neal: i've read a bit about current modern microkernel based - systems, and i'm wondering - <braunr> neal: can a capability be used for both request and replies, or - does messaging need something similar to reply ports ? - <neal> braunr: you want a reply port - <neal> think about a file server: - <neal> the file server publishes a capability to access something - <neal> and multiple entities use it - <neal> if you wanted just bidirectional caps - <braunr> that's the idea i had in mind, i just wondered if it was actually - still the case in practice - <neal> you'd need to create a new capability every time you delegated the - cap - <braunr> yes - <braunr> thanks - <braunr> what about send once rights ? - <neal> also, if you send on a cap and then start waiting on it you could - get your own reply :) - <neal> you can get around send-once rights by using a counter - <braunr> no i mean, is their behaviour still needed/useful ? - <neal> the counter is kernel implemented - <neal> yes - <neal> as an optimization - <braunr> so they're just a special case of capability - <neal> yes - <braunr> not a special capability type of their own - <neal> but they eliminate the constant create/destroy sequence - <braunr> (even if it was already the case at the implementation level in - mach, they were named separately which could confuse people) - <braunr> hm - <braunr> actually, send once rights were used for important notifications - such as dead port notifications - <braunr> is this still handled at the kernel level in modern ukernels ? - <neal> in viengoos, this is called the version field - <neal> see chapter 2 - <neal> - http://www.gnu.org/software/hurd/microkernel/viengoos/documentation/reference-guide.pdf - <braunr> neal: btw, congratulations for viengoos, it really is a very - interesting project: ) - <neal> thanks - <braunr> i don't see the point of rewriting a mach clone after reading - about it eh - <neal> I would definately do the messenger concept again - <neal> but I'd not do persistence - <braunr> i don't fully understand how messengers deal with blocking - <neal> did you read chapter 4? - <braunr> i read all of it but didn't understand everything :) - <braunr> it's quite abstract and i didn't make time to read some of the - source code - <neal> If you have specific questions, I can try to help - <braunr> i'll read those chapter again and formulate my questions after - <neal> I may have to read them as well :) - <braunr> i don't understand how you manage to separate IPC from threading - actually - <braunr> are messengers queues ? - <neal> messengers are super-buffers - <neal> they contain a reference to a thread object - <neal> to send a message, I use a messenger - <neal> I put the data in a buffer - <neal> and then I attach the messenger to the target messenger - <antrik> braunr: my stance is that we should try to incorporate the ideas - from Viengoos into Mach in an evolutionary process... - <neal> this causes an activation to be sent to the target messenger's - thread object - <braunr> neal: which activation ? - <neal> an activation is like a CPU interrupt - <braunr> neal: is it "allocated" at that moment, or taken from the sending - thread ? - <braunr> (i'm not sure my question really makes sense to you :/) - <antrik> braunr: not sure what you are asking exactly; but the basic idea - is that the receiving process preallocates message buffers - <braunr> antrik: maybe, i'm not sure - <antrik> when someone sends a message, it's stored in one of these buffers, - and the process gets a scheduler activation, so it can decide what to do - with it - <neal> antrik is right - <neal> the traget messenger designates a memory buffer - <braunr> i'm wondering about the details of this activation - <braunr> is it similar to thread migration ? - <neal> just before the activation, the data is copied to the messenger's - buffer - <neal> now someone needs to be notified - <neal> (that a message arrived) - <neal> that someone is the thread designated in the target messenger's - thread field - <neal> this is done by an activation - <neal> an activation is just an upcall - <neal> a thread is forced to a particular IP - <neal> an activation isn't a "what" it's a "how" - <neal> I never understood thread migration - <neal> as it's not really about threads - <neal> nor it is about migration - <antrik> neal: what happens if another message comes in before the - activation handling tread is done with the previous one?... - <neal> the messenger is enqueued on the thread object - <neal> it is delivered when the thread is in normal mode - <neal> part of delivering an activation is putting the thread is activation - mode - <neal> when in activation mode, it can't receive any activations - <braunr> i see - <braunr> but then, when a thread receives an activation, does it handle - several queued messengers at once (not to loose events/messages) ? - <neal> (unless it does a blocking receive on a particular messenger, which - is necessary to support memory allocation in activated mode) - <neal> it handles one at a time - <braunr> ah right - <neal> it can't lose events - <braunr> activations are sent per messengers/events - <neal> well, it can - <neal> but it is possible to prevent this - <braunr> neal: also, is message passing completely atomic ? - <neal> I'm not sure what you mean - <neal> which part - <braunr> well, all parts of a message :) - <braunr> in mach, a message can contain several parts - <braunr> data, rights, passing one of them may fail - <braunr> only the header is atomically processed - <neal> it's not atomic in the sense that a thread can observe the data copy - <braunr> that's not what i meant - <braunr> is a message completely transferred or not at all in case of - failure ? - <neal> it may be partially transferred - <braunr> or can it be partially transferred - <braunr> ok - <neal> for instance, if the target thread doesn't provide a memory buffer - <neal> then the data can't be copied - <neal> I don't recall off hand how I dealt with bad addresses - <neal> may be it is not possible - <neal> I don't remember - <neal> sorry - <braunr> but if i read the message structure correctly, there can be one - data block, and several capability addresses in a single message, right ? - <neal> yes - <braunr> ok - <braunr> have you considered passing only one object (either data or - capability) per message ? - <braunr> or is it too inefficient ? - <neal> you at least need a reply port - <neal> s/port/messenger/ - <braunr> yes but can't it be passed separately ? - <neal> then you have server state - <neal> ik - <braunr> hm yes - <braunr> thanks for your answers: ) - <neal> no problem diff --git a/microkernel/viengoos/documentation/reference-guide.pdf b/microkernel/viengoos/documentation/reference-guide.pdf Binary files differdeleted file mode 100644 index 6fbea23b..00000000 --- a/microkernel/viengoos/documentation/reference-guide.pdf +++ /dev/null diff --git a/microkernel/viengoos/grub2-config.diff b/microkernel/viengoos/grub2-config.diff deleted file mode 100644 index e4b1ef40..00000000 --- a/microkernel/viengoos/grub2-config.diff +++ /dev/null @@ -1,47 +0,0 @@ -2009-01-17 Neal H. Walfield <address@hidden> - - * util/i386/pc/grub-mkrescue.in: Add new option --configfile. If - not the set and not the empty string, load it from the generated - config file on boot. - -Index: util/i386/pc/grub-mkrescue.in -=================================================================== ---- util/i386/pc/grub-mkrescue.in (revision 2148) -+++ util/i386/pc/grub-mkrescue.in (working copy) -@@ -49,6 +49,7 @@ - --image-type=TYPE select floppy or cdrom (default) - --emulation=TYPE select El Torito boot emulation type floppy - or none (default) (cdrom only) -+ --configfile=FILE config file to load (default: none) - - grub-mkimage generates a bootable rescue image of the specified type. - -@@ -93,6 +94,9 @@ - echo "Unknown emulation type \`$emulation'" 1>&2 - exit 1 ;; - esac ;; -+ --configfile=*) -+ configfile=`echo "$option" | sed 's/--configfile=//'` -+ ;; - -*) - echo "Unrecognized option \`$option'" 1>&2 - usage -@@ -121,9 +125,15 @@ - ${aux_dir}/boot/grub/ - - modules="biosdisk `cat ${input_dir}/partmap.lst` ${modules}" --for i in ${modules} ; do -- echo "insmod $i" --done > ${aux_dir}/boot/grub/grub.cfg -+{ -+ for i in ${modules} ; do -+ echo "insmod $i" -+ done -+ if test x$configfile != x -+ then -+ echo "configfile $configfile" -+ fi -+} > ${aux_dir}/boot/grub/grub.cfg - - for d in ${overlay}; do - echo "Overlaying $d" diff --git a/microkernel/viengoos/hardware.mdwn b/microkernel/viengoos/hardware.mdwn deleted file mode 100644 index aff70604..00000000 --- a/microkernel/viengoos/hardware.mdwn +++ /dev/null @@ -1,50 +0,0 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -I boot over the network using PXE. - -On my build machine, I have installed a tftpserver. Specifically, I use -the one built into dnscache. In /tftpboot, I have symlinks to pistachio, -sigma0, and the root of the build tree. - -My build machine boots using PXE. It gets an IP address, contacts -my build machine and loads [grub2pxe](http://grub.enbug.org/PXEBOOT). -Note that there is no need to use pxelinux; grub2 is a valid PXE -executable. Further, grub2 uses the PXE interface for accessing the -network, so if your hardware supports PXE, then you do not need to -worry about a network driver. Here is how I build grub2 and the -grub2 image: - - cd ~/src - svn co svn://svn.savannah.gnu.org/grub/trunk/grub2 - cd grub2 - mkdir build - cd build - ../configure --prefix=$HOME/src/grub2/install && make && make install - cd ~/src/grub2/install - bin/grub-mkimage --output=core.img --prefix="(pxe)" pxe pxecmd help reboot serial multiboot pc configfile normal boot - cat lib/grub/i386-pc/pxeboot.img core.img > grub2pxe - -Here is my /tftpboot/grub.cfg, which sends output to the first -[[serial_port]]: - - # Timeout for menu - set timeout=1 - - # Set default boot entry as Entry 0 - set default=0 - - menuentry "Viengoos" { - multiboot /viengoos/laden/laden -o serial -D - module /pistachio - module /sigma0 - module /viengoos/viengoos/viengoos.stripped -D 3 -o serial - module /viengoos/hieronymus/hieronymus.stripped - } diff --git a/microkernel/viengoos/projects.mdwn b/microkernel/viengoos/projects.mdwn deleted file mode 100644 index 971206bb..00000000 --- a/microkernel/viengoos/projects.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Some projects: - -[[!inline -pages="microkernel/viengoos/projects/* and !microkernel/viengoos/projects/*/*" -show=0 -feeds=no -actions=yes]] diff --git a/microkernel/viengoos/projects/address_space_management.mdwn b/microkernel/viengoos/projects/address_space_management.mdwn deleted file mode 100644 index 2d00e4f4..00000000 --- a/microkernel/viengoos/projects/address_space_management.mdwn +++ /dev/null @@ -1,40 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_viengoos]] - -In Viengoos, a process's address space is managed entirely in user -space by the process itself. This creates two interesting problems: -dealing with circular dependencies resulting from having to manage the -address space data structures and accessing and manipulating the -address space data structures. - -First, managing the address space requires resources, which in turn -may require address space (e.g., data structures require memory which -require address space, etc.). We currently break this circular -dependency by trying to keep enough resources in reserve that -allocating resources for managing the address space never requires -more resources than are minimally in the reserve. The reserve is -currently chosen in an ad-hoc fashion. It would be nice to determine -it more systematically. Moreover, it would be nice to reduce the -cases in which a reserve is required. This may be possible by -restructuring some of the code. - -Second, the address space data structures are protected using a single -lock. This not only means that only a single thread can be updating -the address space at a time, but that if a thread faults and the -address space is locked, then the process dead locks! It should be -possible to at least walk the address space using lock-free -techniques. This requires updating the address space construction -code such that all addresses remain valid during any given -manipulation. Second, to avoid the mentioned dead-lock problem, we -try to ensure that accessing the data structures will never result in -a fault. This means protecting the stack. An alternative approach is -to use undo buffers. diff --git a/microkernel/viengoos/projects/capability-aware_compiler.mdwn b/microkernel/viengoos/projects/capability-aware_compiler.mdwn deleted file mode 100644 index b4e465d9..00000000 --- a/microkernel/viengoos/projects/capability-aware_compiler.mdwn +++ /dev/null @@ -1,16 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_viengoos]] - -Modify, e.g., gcc to understand capability semantics and teach gcc how -to optimize it, e.g., how to batch and combine calls. - -This project is deemed suitable for a thesis. diff --git a/microkernel/viengoos/projects/new_hash_function.mdwn b/microkernel/viengoos/projects/new_hash_function.mdwn deleted file mode 100644 index d0374720..00000000 --- a/microkernel/viengoos/projects/new_hash_function.mdwn +++ /dev/null @@ -1,22 +0,0 @@ -[[!meta copyright="Copyright © 2008, 2009, 2010 Free Software Foundation, -Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -[[!tag open_issue_viengoos]] - -The current hash function in libhurd-ihash results in a lot of -collisions when the hash table is 80% full. To overcome this, we keep -hash tables at most 30% full. This represents a fair amount of -overhead. Find a better algorithm. There can either be one that is -appropriate in the general case or one that works well in a relevant, -specific case, e.g., viengoos/object.c uses a hash to find the object -corresponding to a frame, which is keyed on its physical address. - -Note that this applies to the Hurd's [[hurd/libihash]], too. diff --git a/microkernel/viengoos/serial_port.mdwn b/microkernel/viengoos/serial_port.mdwn deleted file mode 100644 index 14efcb9f..00000000 --- a/microkernel/viengoos/serial_port.mdwn +++ /dev/null @@ -1,15 +0,0 @@ -[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="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]]."]]"""]] - -Viengoos can be configured to send output to the serial port (in fact, -this is the only configuration that I use). To talk to the serial -port, I use ser2net, which provides a telnet interface to the serial -port. Be sure to edit /etc/ser2net.conf to use 115200 bps, which -Viengoos uses by default. |