From 1b21d156dd420089325c0905f3814d0e12987f90 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 09:37:40 +0100 Subject: Remove old redirection pages. All URLs will change nevertheless. --- microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn | 11 ----------- 1 file changed, 11 deletions(-) delete mode 100644 microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn b/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn deleted file mode 100644 index 8c67e3e0..00000000 --- a/microkernel/mach/gnumach/hardwarecompatibilitylist.mdwn +++ /dev/null @@ -1,11 +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]]."]]"""]] - -[[meta redir=hardware_compatibility_list]] -- cgit v1.2.3 From ae9e4e22a7ce8b2b56e98ff1708c2e8d42eefd69 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 5 Nov 2008 14:58:33 +0100 Subject: microkernel/mach/gnumach -> microkernel/mach/gnu_mach --- community/gsoc/project_ideas.mdwn | 6 +- contributing.mdwn | 6 +- hurd/building/cross-compiling.mdwn | 2 +- hurd/getting_help.mdwn | 2 +- hurd/libstore.mdwn | 2 +- hurd/running.mdwn | 2 +- microkernel/mach.mdwn | 2 +- microkernel/mach/gnu_mach.mdwn | 30 +++ microkernel/mach/gnu_mach/boot_trace.mdwn | 222 +++++++++++++++++++++ microkernel/mach/gnu_mach/building.mdwn | 114 +++++++++++ microkernel/mach/gnu_mach/building/example.mdwn | 54 +++++ microkernel/mach/gnu_mach/debugging.mdwn | 68 +++++++ .../mach/gnu_mach/hardware_compatibility_list.mdwn | 111 +++++++++++ .../hardware_compatibility_list/discussion.mdwn | 4 + microkernel/mach/gnu_mach/open_issues.mdwn | 19 ++ microkernel/mach/gnu_mach/ports.mdwn | 15 ++ microkernel/mach/gnu_mach/ports/xen.mdwn | 84 ++++++++ microkernel/mach/gnu_mach/ports/xen/internals.mdwn | 14 ++ .../ports/xen/networking_configuration.mdwn | 105 ++++++++++ microkernel/mach/gnu_mach/projects.mdwn | 129 ++++++++++++ .../mach/gnu_mach/projects/clean_up_the_code.mdwn | 121 +++++++++++ microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn | 13 ++ microkernel/mach/gnumach.mdwn | 30 --- microkernel/mach/gnumach/boot_trace.mdwn | 222 --------------------- microkernel/mach/gnumach/building.mdwn | 114 ----------- microkernel/mach/gnumach/building/example.mdwn | 54 ----- microkernel/mach/gnumach/debugging.mdwn | 68 ------- .../mach/gnumach/hardware_compatibility_list.mdwn | 111 ----------- .../hardware_compatibility_list/discussion.mdwn | 4 - microkernel/mach/gnumach/open_issues.mdwn | 19 -- microkernel/mach/gnumach/ports.mdwn | 15 -- microkernel/mach/gnumach/ports/xen.mdwn | 84 -------- microkernel/mach/gnumach/ports/xen/internals.mdwn | 14 -- .../ports/xen/networking_configuration.mdwn | 105 ---------- microkernel/mach/gnumach/projects.mdwn | 129 ------------ .../mach/gnumach/projects/clean_up_the_code.mdwn | 121 ----------- microkernel/mach/gnumach/projects/gdb_stubs.mdwn | 13 -- microkernel/mach/history.mdwn | 2 +- microkernel/mach/mig/building.mdwn | 3 +- sidebar.mdwn | 2 +- 40 files changed, 1118 insertions(+), 1117 deletions(-) create mode 100644 microkernel/mach/gnu_mach.mdwn create mode 100644 microkernel/mach/gnu_mach/boot_trace.mdwn create mode 100644 microkernel/mach/gnu_mach/building.mdwn create mode 100644 microkernel/mach/gnu_mach/building/example.mdwn create mode 100644 microkernel/mach/gnu_mach/debugging.mdwn create mode 100644 microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn create mode 100644 microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn create mode 100644 microkernel/mach/gnu_mach/open_issues.mdwn create mode 100644 microkernel/mach/gnu_mach/ports.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen/internals.mdwn create mode 100644 microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn create mode 100644 microkernel/mach/gnu_mach/projects.mdwn create mode 100644 microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn create mode 100644 microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn delete mode 100644 microkernel/mach/gnumach.mdwn delete mode 100644 microkernel/mach/gnumach/boot_trace.mdwn delete mode 100644 microkernel/mach/gnumach/building.mdwn delete mode 100644 microkernel/mach/gnumach/building/example.mdwn delete mode 100644 microkernel/mach/gnumach/debugging.mdwn delete mode 100644 microkernel/mach/gnumach/hardware_compatibility_list.mdwn delete mode 100644 microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn delete mode 100644 microkernel/mach/gnumach/open_issues.mdwn delete mode 100644 microkernel/mach/gnumach/ports.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen/internals.mdwn delete mode 100644 microkernel/mach/gnumach/ports/xen/networking_configuration.mdwn delete mode 100644 microkernel/mach/gnumach/projects.mdwn delete mode 100644 microkernel/mach/gnumach/projects/clean_up_the_code.mdwn delete mode 100644 microkernel/mach/gnumach/projects/gdb_stubs.mdwn (limited to 'microkernel/mach') diff --git a/community/gsoc/project_ideas.mdwn b/community/gsoc/project_ideas.mdwn index c4b665b7..8f2fe385 100644 --- a/community/gsoc/project_ideas.mdwn +++ b/community/gsoc/project_ideas.mdwn @@ -340,7 +340,7 @@ GSoC 2008. He is still working on some outstanding issues. Although a driver framework in userspace would be desirable, presently the Hurd uses kernel drivers in the microkernel, -[[GNU_Mach|microkernel/mach/gnumach]]. (And changing this would be far beyond a +[[microkernel/mach/GNU_Mach]]. (And changing this would be far beyond a GSoC project...) The problem is that the drivers in GNU Mach are presently old Linux drivers @@ -590,7 +590,7 @@ pthreads. The Hurd presently has no sound support. Fixing this, [[GNU_Savannah_task 5485]], requires two steps: the first is to port some other kernel's drivers to -[[GNU_Mach|microkernel/mach/gnumach]] so we can get access to actual sound +[[microkernel/mach/GNU_Mach]] so we can get access to actual sound hardware. The second is to implement a userspace server ([[hurd/translator]]), that implements an interface on top of the kernel device that can be used by applications -- probably OSS or maybe ALSA. @@ -741,7 +741,7 @@ directories and attaching other translators. Although there are some attempts to move to a more modern microkernel alltogether, the current Hurd implementation is based on -[[GNU_Mach|microkernel/mach/gnumach]], which is only a slightly modified +[[microkernel/mach/GNU_Mach]], which is only a slightly modified variant of the original CMU [[microkernel/Mach]]. Unfortunately, Mach was created about two decades ago, and is in turn based on diff --git a/contributing.mdwn b/contributing.mdwn index 4b731065..f21a6f32 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -33,7 +33,7 @@ There are essential two kinds of Hurd system designs. ## Hurd on Mach For one there's the implementation of the *[[Hurd]] running on the -[[GNU_Mach_microkernel|microkernel/mach/gnumach]]*. This is what is commonly +[[microkernel/mach/GNU_Mach]] microkernel*. This is what is commonly meant when people are talking about GNU/Hurd systems. This system has mostly been designed and implemented [in the @@ -84,8 +84,8 @@ Here is a [[list_of_open_issues|hurd/Open_Issues]] for the [[GNU_Hurd|hurd]]. ### Open Issues: GNU Mach -Here is a [[list_of_open_issues|microkernel/mach/gnumach/Open_Issues]] for -[[GNU_Mach|microkernel/mach/gnumach]]. +Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/Open_Issues]] for +[[microkernel/mach/GNU_Mach]]. ### Open Issues: GNU MIG diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 11afc97f..31722ead 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -98,7 +98,7 @@ guarantee is given. Always the preferred version is listed first. `gcc-4_3-branch` needs. --> -* `src/gnumach`: [[GNU_Mach|microkernel/mach/gnumach]] +* `src/gnumach`: [[microkernel/mach/GNU_Mach]] * CVS `gnumach-1-branch` diff --git a/hurd/getting_help.mdwn b/hurd/getting_help.mdwn index 342410dd..c4f80ff9 100644 --- a/hurd/getting_help.mdwn +++ b/hurd/getting_help.mdwn @@ -11,7 +11,7 @@ is included in the section entitled # Essential Documentation * [[FAQ]] -* [[microkernel/mach/gnumach/Hardware_Compatibility_List]] +* [[microkernel/mach/gnu_mach/Hardware_Compatibility_List]] # Forums diff --git a/hurd/libstore.mdwn b/hurd/libstore.mdwn index ab649ebc..3de42be3 100644 --- a/hurd/libstore.mdwn +++ b/hurd/libstore.mdwn @@ -9,7 +9,7 @@ is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] `libstore` is more than just a thin layer between -[[GNU_Mach|microkernel/mach/gnumach]] devices (`hd0` for example) and the +[[microkernel/mach/GNU_Mach]] devices (`hd0` for example) and the device node below `/dev`... # Available Stores diff --git a/hurd/running.mdwn b/hurd/running.mdwn index 162bc9ea..78815099 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -9,7 +9,7 @@ is included in the section entitled [[GNU_Free_Documentation_License|/fdl]]."]]"""]] * [[Distrib]] - Distributions based on the Hurd -* [[microkernel/mach/gnumach/ports/Xen]] - In Xen +* [[microkernel/mach/gnu_mach/ports/Xen]] - In Xen * [[Live_CD]] * [[QEMU]] - In QEMU * [[vmware]] (**non-free!**) diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 078b531f..7e63c724 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -9,7 +9,7 @@ microkernel currently used by the [[Hurd]]. # Implementations -* [[GNUMach]] +* [[GNU_Mach]] * [[Mach/OskitMach]] - A Once Successor of Mach based on OSKit * [Apple's Darwin](http://developer.apple.com/darwin/) ([API](http://developer.apple.com/documentation/Darwin/Conceptual/KernelProgramming/index.html)) (**non-free**) diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn new file mode 100644 index 00000000..d45549f5 --- /dev/null +++ b/microkernel/mach/gnu_mach.mdwn @@ -0,0 +1,30 @@ +[[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]]."]]"""]] + +GNU Mach is currently used by the GNU [[Hurd]]. + +GNU Mach 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. + + +# Development + +* [[Building]] +* [[Debugging]] +* [[Boot_Trace]] +* [[Projects]] + * [[Rules]] + * [[Open_Issues]] diff --git a/microkernel/mach/gnu_mach/boot_trace.mdwn b/microkernel/mach/gnu_mach/boot_trace.mdwn new file mode 100644 index 00000000..a08384f0 --- /dev/null +++ b/microkernel/mach/gnu_mach/boot_trace.mdwn @@ -0,0 +1,222 @@ +[[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]]."]]"""]] + +`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 + +>> [...] + +>> vm\_pageout + +>> Does not return. diff --git a/microkernel/mach/gnu_mach/building.mdwn b/microkernel/mach/gnu_mach/building.mdwn new file mode 100644 index 00000000..ef0d8553 --- /dev/null +++ b/microkernel/mach/gnu_mach/building.mdwn @@ -0,0 +1,114 @@ +Additional to the following text, a further [[example]] has be posted. + + +# Building [[GNU_Mach]] from Source + +If you want to build the [[GNU_Mach]] 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 + +### Developers's RCS + +See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach + +(Most probably you want to get hold of the *GNU Mach 1 branch* and not the +trunk, which is also what we've done above.) + +You then have to create the automatically generatable files: + + $ ( cd gnumach && autoreconf --install ) + +### What Debian is currently using + +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`. + +## Preparing for the Build + +### ... on Debian systems + +Building GNU Mach requires the *build-essential* and *fakeroot* packages, their +dependencies and additional packages that are specified by the source gnumach +package: + + # apt-get install build-essential fakeroot + # apt-get build-dep gnumach + +### ... on non-Debian systems + +Apart from the case that you only want to install GNU Mach's header files (see +below), building GNU Mach requires you to have the Mach Interface Generator +installed. See [[building_MIG|mig/building]] about how to do that, then come +back here. + +Additionally, building GNU Mach requires a C compiler, a standard C library and +your favourite flavor of awk (gawk) and GNU make. + +## Building and Installing + +### ... Debian `.deb` files + +Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. + + $ cd gnumach-20050801 + +Start the build process with + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +[[GNU_Mach]] is now building. To use the new kernel, you must install the +resulting `.deb` package which is located one directory above the build +directory and has a similar name as the build directory, e.g. + + # dpkg -i ../gnumach_20050801-4_hurd-i386.deb + +You can now reboot your computer and enjoy the new kernel. + +### [TODO] + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +it: + + $ [...]/gnumach-1-branch/configure [TODO] + +Build the kernel image: + + $ make gnumach.gz + +Optionally run the (tiny) test suite: + + $ make check + +You can then install and use `gnumach.gz`. + +[TODO.] + +### Installing only the Header Files + +GNU Mach should be built in a separate directory: + + $ mkdir gnumach-build + $ cd gnumach-build + +Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +it: + + $ [...]/gnumach-1-branch/configure --prefix= + +Install the header files into e.g. `~/gnu/include/`: + + $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnu_mach/building/example.mdwn b/microkernel/mach/gnu_mach/building/example.mdwn new file mode 100644 index 00000000..6da05c5b --- /dev/null +++ b/microkernel/mach/gnu_mach/building/example.mdwn @@ -0,0 +1,54 @@ +[[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]]."]]"""]] + +## Compiling GNU Mach microkernel + +Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. + +* gcc version: 3.3.5 +* GNU sed version: 4.1.2 +* GNU make version: 3.8 +* mig version: 1.3-4 + +Obtained gnumach-1-branch sources from cvs: + + export CVS_RSH="ssh" + cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach + +Obtained mig_1.3-4_i386.deb from +http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: + + dpkg -i mig_1.3-4_i386.deb + +Entered into the gnumach sources and did the following for compilation: + + mkdir build + cd build + ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ + --enable-kdb --enable-ide + make + +The kernel file is created in the build directory. Move it to /boot on the +testing x86 system Hurd partition. Rename it as gnumach1 and compress it: + + mv kernel gnumach1 + gzip gnumach1 + +Add a new entry on the testing machine /boot/grub/menu.lst to boot the new +kernel. + + title GNU Hurd K10 Compiled gnumach + kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s + module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\ + --host-priv-port=${host-port} --device-master-port=${device-port} \\ + --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume) + module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) + +Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnu_mach/debugging.mdwn b/microkernel/mach/gnu_mach/debugging.mdwn new file mode 100644 index 00000000..fa2a9d42 --- /dev/null +++ b/microkernel/mach/gnu_mach/debugging.mdwn @@ -0,0 +1,68 @@ +[[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 has a built-in kernel debugger. +[Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). + + +When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly +[use GDB on the running +kernel](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC36). + + +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. + + +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. diff --git a/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn b/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn new file mode 100644 index 00000000..09882467 --- /dev/null +++ b/microkernel/mach/gnu_mach/hardware_compatibility_list.mdwn @@ -0,0 +1,111 @@ +[[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]]."]]"""]] + +# 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 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. If you find a specific IDE +drive that does not work, make a note of the model and technical specifications +here. + +[[toggle id="SATA" text="SATA drives may work in compatibility mode."]] + + +[[toggleable id="SATA" text=""" +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/gnu_mach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn new file mode 100644 index 00000000..69ca3190 --- /dev/null +++ b/microkernel/mach/gnu_mach/hardware_compatibility_list/discussion.mdwn @@ -0,0 +1,4 @@ +Further information may still be found on + +and could perhaps be incorporated into that page. +--[[tschwinge]] diff --git a/microkernel/mach/gnu_mach/open_issues.mdwn b/microkernel/mach/gnu_mach/open_issues.mdwn new file mode 100644 index 00000000..433ec3ef --- /dev/null +++ b/microkernel/mach/gnu_mach/open_issues.mdwn @@ -0,0 +1,19 @@ +[[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]]."]]"""]] + +[[meta title="Open Issues"]] + +This is a dumping ground for open issues for GNU Mach. + +[[inline +pages="microkernel/mach/gnumach/open_issues/* and !*/discussion" +show=0 +actions=yes +rootpage="microkernel/mach/gnumach/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/gnu_mach/ports.mdwn b/microkernel/mach/gnu_mach/ports.mdwn new file mode 100644 index 00000000..00cdee8c --- /dev/null +++ b/microkernel/mach/gnu_mach/ports.mdwn @@ -0,0 +1,15 @@ +[[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]]."]]"""]] + + * x86. This is the main port. + * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. + * Alpha. Was once started, but isn't in a usable state either. + + * [[Xen]] diff --git a/microkernel/mach/gnu_mach/ports/xen.mdwn b/microkernel/mach/gnu_mach/ports/xen.mdwn new file mode 100644 index 00000000..cdb4e2de --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen.mdwn @@ -0,0 +1,84 @@ +[[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]]."]]"""]] + +[[toc ]] + +## Xen dom0, PAE-disabled hypervisor + +/!\ Since GNU Mach doesn't handle PAE yet, you'll need a PAE-disabled hypervisor. + +On Debian Lenny, for example, you can install xen-hypervisor-3.2-1-i386-nonpae. + +This also means that you'll currently need a PAE-disabled `dom0`. +[[Stefan_Siegl|stesie]] is providing a PAE-disabled Linux kernel image at +. + +You can either get binaries at or build them yourself. + +- Copy `gnumach-xen` and `hurd-modules` to your dom0 /boot. +- 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. + +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" + memory = 256 + disk = ['phy:sda4,hda,w'] + extra = "root=device:hd0" + vif = [ '' ] + ramdisk = "/boot/hurd-modules" + +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 you just need to install and boot non-PAE hypervisor and kernel. + +## 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-based one! + +--- + +[[Internals]]. + +[[GNU_Savannah_task 5468]], [[GNU_Savannah_task 6584]]. diff --git a/microkernel/mach/gnu_mach/ports/xen/internals.mdwn b/microkernel/mach/gnu_mach/ports/xen/internals.mdwn new file mode 100644 index 00000000..09e707ea --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen/internals.mdwn @@ -0,0 +1,14 @@ +[[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/gnu_mach/ports/xen/networking_configuration.mdwn b/microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn new file mode 100644 index 00000000..71a72bac --- /dev/null +++ b/microkernel/mach/gnu_mach/ports/xen/networking_configuration.mdwn @@ -0,0 +1,105 @@ +[[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/gnu_mach/projects.mdwn b/microkernel/mach/gnu_mach/projects.mdwn new file mode 100644 index 00000000..9ace6270 --- /dev/null +++ b/microkernel/mach/gnu_mach/projects.mdwn @@ -0,0 +1,129 @@ +[[meta copyright="Copyright © 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]]."]]"""]] + +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]] + + * 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 + + + * Improve the external pagers interface + + * Implement 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: + + here's a fun project: port the mach interface to Linux + (e.g., via kernel modifications) + or, to posix/glibc + (mmap, some minimal ptrace, etc.) + + * From the [Hurd bits at + sourceforge.net](http://sourceforge.net/projects/hurd): + , 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/gnu_mach/projects/clean_up_the_code.mdwn b/microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn new file mode 100644 index 00000000..875bb8cd --- /dev/null +++ b/microkernel/mach/gnu_mach/projects/clean_up_the_code.mdwn @@ -0,0 +1,121 @@ +[[meta copyright="Copyright © 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]]."]]"""]] + +# 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 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/gnu_mach/projects/gdb_stubs.mdwn b/microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn new file mode 100644 index 00000000..9a11a82b --- /dev/null +++ b/microkernel/mach/gnu_mach/projects/gdb_stubs.mdwn @@ -0,0 +1,13 @@ +[[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]]."]]"""]] + + * + + * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) diff --git a/microkernel/mach/gnumach.mdwn b/microkernel/mach/gnumach.mdwn deleted file mode 100644 index d45549f5..00000000 --- a/microkernel/mach/gnumach.mdwn +++ /dev/null @@ -1,30 +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]]."]]"""]] - -GNU Mach is currently used by the GNU [[Hurd]]. - -GNU Mach 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. - - -# Development - -* [[Building]] -* [[Debugging]] -* [[Boot_Trace]] -* [[Projects]] - * [[Rules]] - * [[Open_Issues]] diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn deleted file mode 100644 index a08384f0..00000000 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ /dev/null @@ -1,222 +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]]."]]"""]] - -`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 - ->> [...] - ->> vm\_pageout - ->> Does not return. diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn deleted file mode 100644 index 27573b64..00000000 --- a/microkernel/mach/gnumach/building.mdwn +++ /dev/null @@ -1,114 +0,0 @@ -Additional to the following text, a further [[example]] has be posted. - - -# Building [[GNUMach]] from Source - -If you want to build the [[GNUMach]] kernel yourself instead of just using a -pre-built binary, follow these instructions. - -The unpacked source tree is around 20 MiB, and the build tree (with all drivers -enabled) is around 50 MiB. - -## Getting the Source Code - -### Developers's RCS - -See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach - -(Most probably you want to get hold of the *GNU Mach 1 branch* and not the -trunk, which is also what we've done above.) - -You then have to create the automatically generatable files: - - $ ( cd gnumach && autoreconf --install ) - -### What Debian is currently using - -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`. - -## Preparing for the Build - -### ... on Debian systems - -Building GNU Mach requires the *build-essential* and *fakeroot* packages, their -dependencies and additional packages that are specified by the source gnumach -package: - - # apt-get install build-essential fakeroot - # apt-get build-dep gnumach - -### ... on non-Debian systems - -Apart from the case that you only want to install GNU Mach's header files (see -below), building GNU Mach requires you to have the Mach Interface Generator -installed. See [[building_MIG|mig/building]] about how to do that, then come -back here. - -Additionally, building GNU Mach requires a C compiler, a standard C library and -your favourite flavor of awk (gawk) and GNU make. - -## Building and Installing - -### ... Debian `.deb` files - -Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. - - $ cd gnumach-20050801 - -Start the build process with - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -[[GNUMach]] is now building. To use the new kernel, you must install the -resulting `.deb` package which is located one directory above the build -directory and has a similar name as the build directory, e.g. - - # dpkg -i ../gnumach_20050801-4_hurd-i386.deb - -You can now reboot your computer and enjoy the new kernel. - -### [TODO] - -GNU Mach should be built in a separate directory: - - $ mkdir gnumach-build - $ cd gnumach-build - -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: - - $ [...]/gnumach-1-branch/configure [TODO] - -Build the kernel image: - - $ make gnumach.gz - -Optionally run the (tiny) test suite: - - $ make check - -You can then install and use `gnumach.gz`. - -[TODO.] - -### Installing only the Header Files - -GNU Mach should be built in a separate directory: - - $ mkdir gnumach-build - $ cd gnumach-build - -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure -it: - - $ [...]/gnumach-1-branch/configure --prefix= - -Install the header files into e.g. `~/gnu/include/`: - - $ make DESTDIR=~/gnu install-data diff --git a/microkernel/mach/gnumach/building/example.mdwn b/microkernel/mach/gnumach/building/example.mdwn deleted file mode 100644 index 6da05c5b..00000000 --- a/microkernel/mach/gnumach/building/example.mdwn +++ /dev/null @@ -1,54 +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]]."]]"""]] - -## Compiling GNU Mach microkernel - -Host development system is IBM T41 running Debian Sarge 3.1r0a GNU/Linux. - -* gcc version: 3.3.5 -* GNU sed version: 4.1.2 -* GNU make version: 3.8 -* mig version: 1.3-4 - -Obtained gnumach-1-branch sources from cvs: - - export CVS_RSH="ssh" - cvs -z3 -d:ext:anoncvs@ savannah.gnu.org:/cvsroot/hurd co -r gnumach-1-branch gnumach - -Obtained mig_1.3-4_i386.deb from -http://www.hadrons.org/~guillem/debian/pool/main/mig/. Installed it using dpkg: - - dpkg -i mig_1.3-4_i386.deb - -Entered into the gnumach sources and did the following for compilation: - - mkdir build - cd build - ../configure --host=i386-unknown-gnu0.2 --build=i586-pc-linux-gnu \ - --enable-kdb --enable-ide - make - -The kernel file is created in the build directory. Move it to /boot on the -testing x86 system Hurd partition. Rename it as gnumach1 and compress it: - - mv kernel gnumach1 - gzip gnumach1 - -Add a new entry on the testing machine /boot/grub/menu.lst to boot the new -kernel. - - title GNU Hurd K10 Compiled gnumach - kernel (hd0,3)/boot/gnumach1.gz root=device:hd2s4 -s - module (hd0,3)/hurd/ext2fs.static--multiboot-command-line=${kernel-command-line} \\ - --host-priv-port=${host-port} --device-master-port=${device-port} \\ - --exec-server-task=${exec-task} -T typed ${root} $(task-create)$(task-resume) - module (hd0,3)/lib/ld.so.1 /hurd/exec $(exec-task=task-create) - -Reboot into the new compiled mygnumach1.gz kernel! diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn deleted file mode 100644 index fa2a9d42..00000000 --- a/microkernel/mach/gnumach/debugging.mdwn +++ /dev/null @@ -1,68 +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 has a built-in kernel debugger. -[Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). - - -When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly -[use GDB on the running -kernel](http://fabrice.bellard.free.fr/qemu/qemu-doc.html#SEC36). - - -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. - - -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. diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn deleted file mode 100644 index 09882467..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ /dev/null @@ -1,111 +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]]."]]"""]] - -# 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 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. If you find a specific IDE -drive that does not work, make a note of the model and technical specifications -here. - -[[toggle id="SATA" text="SATA drives may work in compatibility mode."]] - - -[[toggleable id="SATA" text=""" -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 69ca3190..00000000 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ /dev/null @@ -1,4 +0,0 @@ -Further information may still be found on - -and could perhaps be incorporated into that page. ---[[tschwinge]] diff --git a/microkernel/mach/gnumach/open_issues.mdwn b/microkernel/mach/gnumach/open_issues.mdwn deleted file mode 100644 index 433ec3ef..00000000 --- a/microkernel/mach/gnumach/open_issues.mdwn +++ /dev/null @@ -1,19 +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]]."]]"""]] - -[[meta title="Open Issues"]] - -This is a dumping ground for open issues for GNU Mach. - -[[inline -pages="microkernel/mach/gnumach/open_issues/* and !*/discussion" -show=0 -actions=yes -rootpage="microkernel/mach/gnumach/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn deleted file mode 100644 index 00cdee8c..00000000 --- a/microkernel/mach/gnumach/ports.mdwn +++ /dev/null @@ -1,15 +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]]."]]"""]] - - * x86. This is the main port. - * [PowerPC](http://www.pjbruin.dds.nl/hurd/). Is not in a usable state. - * Alpha. Was once started, but isn't in a usable state either. - - * [[Xen]] diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn deleted file mode 100644 index cdb4e2de..00000000 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ /dev/null @@ -1,84 +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]]."]]"""]] - -[[toc ]] - -## Xen dom0, PAE-disabled hypervisor - -/!\ Since GNU Mach doesn't handle PAE yet, you'll need a PAE-disabled hypervisor. - -On Debian Lenny, for example, you can install xen-hypervisor-3.2-1-i386-nonpae. - -This also means that you'll currently need a PAE-disabled `dom0`. -[[Stefan_Siegl|stesie]] is providing a PAE-disabled Linux kernel image at -. - -You can either get binaries at or build them yourself. - -- Copy `gnumach-xen` and `hurd-modules` to your dom0 /boot. -- 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. - -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" - memory = 256 - disk = ['phy:sda4,hda,w'] - extra = "root=device:hd0" - vif = [ '' ] - ramdisk = "/boot/hurd-modules" - -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 you just need to install and boot non-PAE hypervisor and kernel. - -## 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-based one! - ---- - -[[Internals]]. - -[[GNU_Savannah_task 5468]], [[GNU_Savannah_task 6584]]. diff --git a/microkernel/mach/gnumach/ports/xen/internals.mdwn b/microkernel/mach/gnumach/ports/xen/internals.mdwn deleted file mode 100644 index 09e707ea..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 71a72bac..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 9ace6270..00000000 --- a/microkernel/mach/gnumach/projects.mdwn +++ /dev/null @@ -1,129 +0,0 @@ -[[meta copyright="Copyright © 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]]."]]"""]] - -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]] - - * 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 - - - * Improve the external pagers interface - - * Implement 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: - - here's a fun project: port the mach interface to Linux - (e.g., via kernel modifications) - or, to posix/glibc - (mmap, some minimal ptrace, etc.) - - * From the [Hurd bits at - sourceforge.net](http://sourceforge.net/projects/hurd): - , 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 875bb8cd..00000000 --- a/microkernel/mach/gnumach/projects/clean_up_the_code.mdwn +++ /dev/null @@ -1,121 +0,0 @@ -[[meta copyright="Copyright © 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]]."]]"""]] - -# 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 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 9a11a82b..00000000 --- a/microkernel/mach/gnumach/projects/gdb_stubs.mdwn +++ /dev/null @@ -1,13 +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]]."]]"""]] - - * - - * [ChangeLog.gdb](http://cvs.savannah.gnu.org/viewvc/gnumach/ChangeLog.gdb?root=hurd&view=markup&pathrev=gnumach-1-branch-gdb-branch) diff --git a/microkernel/mach/history.mdwn b/microkernel/mach/history.mdwn index a8951737..8f4b528b 100644 --- a/microkernel/mach/history.mdwn +++ b/microkernel/mach/history.mdwn @@ -41,7 +41,7 @@ Meanwhile, OSKit became unmaintained, thus posing more of a burden on than being 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]]. +list of [[gnu_mach/projects]]. # Status of the project diff --git a/microkernel/mach/mig/building.mdwn b/microkernel/mach/mig/building.mdwn index ee299166..2ec75e38 100644 --- a/microkernel/mach/mig/building.mdwn +++ b/microkernel/mach/mig/building.mdwn @@ -29,7 +29,8 @@ Building the Mach Interface Generator requires the _build-essential_ and _fakero Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. -Additionally, you need to have GNU Mach's header files installed. See [[mach/gnumach/building]] about how to do that, then come back here. +Additionally, you need to have GNU Mach's header files installed. See +[[mach/gnu_mach/building]] about how to do that, then come back here. ## Building and Installing diff --git a/sidebar.mdwn b/sidebar.mdwn index 0ac0561c..a368c6c3 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -22,7 +22,7 @@ Hurd! * *[[Hurd/Documentation]]* * *[[hurd/Running]]*"]] * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" - * *[[GNU_Mach|microkernel/mach/gnumach]]* + * *[[microkernel/mach/GNU_Mach]]* * *[[microkernel/mach/Documentation]]*"]] --- -- cgit v1.2.3 From a9accad064758577799a0ef2fb8f6242ef815829 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 07:55:26 +0100 Subject: Remove old logos. --- hurd.mdwn | 2 -- hurd/logo.png | Bin 15125 -> 0 bytes hurd/running/debian.mdwn | 2 -- hurd/running/debian/logo.png | Bin 2463 -> 0 bytes hurd/running/gnu.mdwn | 2 -- hurd/running/gnu/gnu.mdwn | 2 -- hurd/running/gnu/logo.png | Bin 3112 -> 0 bytes microkernel/mach.mdwn | 2 -- microkernel/mach/logo.png | Bin 13617 -> 0 bytes microkernel/mach/mig.mdwn | 2 -- microkernel/mach/mig/logo.png | Bin 23622 -> 0 bytes 11 files changed, 12 deletions(-) delete mode 100644 hurd/logo.png delete mode 100644 hurd/running/debian/logo.png delete mode 100644 hurd/running/gnu/logo.png delete mode 100644 microkernel/mach/logo.png delete mode 100644 microkernel/mach/mig/logo.png (limited to 'microkernel/mach') diff --git a/hurd.mdwn b/hurd.mdwn index 2805ddfc..4bf43873 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - [[toc ]] # Introduction diff --git a/hurd/logo.png b/hurd/logo.png deleted file mode 100644 index a892b47d..00000000 Binary files a/hurd/logo.png and /dev/null differ diff --git a/hurd/running/debian.mdwn b/hurd/running/debian.mdwn index f291b75b..f80c1cfc 100644 --- a/hurd/running/debian.mdwn +++ b/hurd/running/debian.mdwn @@ -1,7 +1,5 @@ [[meta title="Debian GNU/Hurd"]] -[[img logo.png]] - - Debian [[FAQ]] -- Frequently Asked Questions - [[After_install]] -- Do this to get networking, new console and X - [Presentation](http://people.debian.org/~mbanck/talks/hurd_lt2004/html/) diff --git a/hurd/running/debian/logo.png b/hurd/running/debian/logo.png deleted file mode 100644 index 068d9584..00000000 Binary files a/hurd/running/debian/logo.png and /dev/null differ diff --git a/hurd/running/gnu.mdwn b/hurd/running/gnu.mdwn index 2ae2f2ca..26d93279 100644 --- a/hurd/running/gnu.mdwn +++ b/hurd/running/gnu.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - # The GNU Operating System The GNU Operating System, or GNU System as it is more commonly known, will be a diff --git a/hurd/running/gnu/gnu.mdwn b/hurd/running/gnu/gnu.mdwn index 2a3629d7..3ee5f657 100644 --- a/hurd/running/gnu/gnu.mdwn +++ b/hurd/running/gnu/gnu.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - ## GNU, FSF & RMS GNU stands for GNU's Not [[Unix]]. It is a project announced in 1983 by diff --git a/hurd/running/gnu/logo.png b/hurd/running/gnu/logo.png deleted file mode 100644 index 50c392cf..00000000 Binary files a/hurd/running/gnu/logo.png and /dev/null differ diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 7e63c724..594a74f9 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - Mach is a so-called first generation [[microkernel]]. It is the microkernel currently used by the [[Hurd]]. diff --git a/microkernel/mach/logo.png b/microkernel/mach/logo.png deleted file mode 100644 index 94951acf..00000000 Binary files a/microkernel/mach/logo.png and /dev/null differ diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index c620420a..cf6d95bb 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,5 +1,3 @@ -[[img logo.png]] - The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an interface definition, it creates stubs to [[invoke]] object methods and to demultiplex incoming messages. These stubs conveniently hide diff --git a/microkernel/mach/mig/logo.png b/microkernel/mach/mig/logo.png deleted file mode 100644 index cdfec179..00000000 Binary files a/microkernel/mach/mig/logo.png and /dev/null differ -- cgit v1.2.3 From 9ef4358330ec422c518a0094bc965f3476466882 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 08:09:23 +0100 Subject: Add copyright and licensing header. --- microkernel/mach/mig.mdwn | 11 +++++++++++ 1 file changed, 11 insertions(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index cf6d95bb..5f09621d 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -1,3 +1,14 @@ +[[meta copyright="Copyright © 2001, 2002, 2003, 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 Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an interface definition, it creates stubs to [[invoke]] object methods and to demultiplex incoming messages. These stubs conveniently hide -- cgit v1.2.3 From 65ad34e710723380896dd7d2d193afc62116ad89 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 08:29:26 +0100 Subject: [[microkernel/mach/mig/gnu_mig]]: New; move most content there. --- contributing.mdwn | 8 +- hurd/building/cross-compiling.mdwn | 2 +- microkernel/mach.mdwn | 2 +- microkernel/mach/gnu_mach/building.mdwn | 2 +- microkernel/mach/mig.mdwn | 12 +- microkernel/mach/mig/building.mdwn | 72 --------- microkernel/mach/mig/discussion.mdwn | 17 --- microkernel/mach/mig/gnu_mig.mdwn | 24 +++ microkernel/mach/mig/gnu_mig/building.mdwn | 73 +++++++++ microkernel/mach/mig/gnu_mig/open_issues.mdwn | 20 +++ .../open_issues/duplicate_inclusion_guards.mdwn | 14 ++ microkernel/mach/mig/open_issues.mdwn | 19 --- .../open_issues/duplicate_inclusion_guards.mdwn | 14 -- mig-download.html | 167 --------------------- mig.html | 125 --------------- sidebar.mdwn | 28 ++-- 16 files changed, 159 insertions(+), 440 deletions(-) delete mode 100644 microkernel/mach/mig/building.mdwn delete mode 100644 microkernel/mach/mig/discussion.mdwn create mode 100644 microkernel/mach/mig/gnu_mig.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/building.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/open_issues.mdwn create mode 100644 microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn delete mode 100644 microkernel/mach/mig/open_issues.mdwn delete mode 100644 microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn delete mode 100644 mig-download.html delete mode 100644 mig.html (limited to 'microkernel/mach') diff --git a/contributing.mdwn b/contributing.mdwn index f21a6f32..698d03b3 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -80,17 +80,17 @@ doesn't work or suit you and try to improve that. ### Open Issues: GNU Hurd -Here is a [[list_of_open_issues|hurd/Open_Issues]] for the [[GNU_Hurd|hurd]]. +Here is a [[list_of_open_issues|hurd/open_issues]] for the [[GNU_Hurd|hurd]]. ### Open Issues: GNU Mach -Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/Open_Issues]] for +Here is a [[list_of_open_issues|microkernel/mach/gnu_mach/open_issues]] for [[microkernel/mach/GNU_Mach]]. ### Open Issues: GNU MIG -Here is a [[list_of_open_issues|microkernel/mach/mig/Open_Issues]] for -[[GNU_MIG|microkernel/mach/mig]]. +Here is a [[list_of_open_issues|microkernel/mach/mig/gnu_mig/open_issues]] for +[[microkernel/mach/mig/GNU_MIG]]. diff --git a/hurd/building/cross-compiling.mdwn b/hurd/building/cross-compiling.mdwn index 31722ead..e548c75c 100644 --- a/hurd/building/cross-compiling.mdwn +++ b/hurd/building/cross-compiling.mdwn @@ -110,7 +110,7 @@ guarantee is given. Always the preferred version is listed first. $ ( cd gnumach-1-branch/ && autoreconf -vfi ) -* `src/mig`: [[GNU_Mach_Interface_Generator|microkernel/mach/mig]] +* `src/mig`: [[microkernel/mach/mig/GNU_MIG]] * CVS `HEAD` diff --git a/microkernel/mach.mdwn b/microkernel/mach.mdwn index 594a74f9..9d3289b4 100644 --- a/microkernel/mach.mdwn +++ b/microkernel/mach.mdwn @@ -13,4 +13,4 @@ microkernel currently used by the [[Hurd]]. # Related -* [[Mach_Interface_Generator|mig]] +* [[Mach_Interface_Generator_(MIG)|mig]] diff --git a/microkernel/mach/gnu_mach/building.mdwn b/microkernel/mach/gnu_mach/building.mdwn index ef0d8553..073c68a3 100644 --- a/microkernel/mach/gnu_mach/building.mdwn +++ b/microkernel/mach/gnu_mach/building.mdwn @@ -47,7 +47,7 @@ package: Apart from the case that you only want to install GNU Mach's header files (see below), building GNU Mach requires you to have the Mach Interface Generator -installed. See [[building_MIG|mig/building]] about how to do that, then come +installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come back here. Additionally, building GNU Mach requires a C compiler, a standard C library and diff --git a/microkernel/mach/mig.mdwn b/microkernel/mach/mig.mdwn index 5f09621d..eb1c0906 100644 --- a/microkernel/mach/mig.mdwn +++ b/microkernel/mach/mig.mdwn @@ -12,11 +12,11 @@ is included in the section entitled The Mach Interface Generator (MIG) is an [[IDL]] compiler. Based on an interface definition, it creates stubs to [[invoke]] object methods and to demultiplex incoming messages. These stubs conveniently hide -the details of Mach's [[IPC]] machinery. +the details of Mach's [[IPC]] machinery and make it easy to implement +and use Mach [[interface]]s as [[remote_procedure_calls_(RPC)|rpc]]. -GNU MIG is fully compatible with OSF MIG. - -* MIG's [homepage](http://www.gnu.org/software/hurd/mig.html) * [[Documentation]] -* [[Building]] - Building (and obtaining) MIG -* [[Open_Issues]] + +# Implementations + + * [[GNU_MIG]] diff --git a/microkernel/mach/mig/building.mdwn b/microkernel/mach/mig/building.mdwn deleted file mode 100644 index 2ec75e38..00000000 --- a/microkernel/mach/mig/building.mdwn +++ /dev/null @@ -1,72 +0,0 @@ -# Building the Mach Interface Generator from Source - -If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. - -## Getting the Source Code - -You can chose between getting the [sources from the developers's rcs](http://www.gnu.org/software/hurd/mig-download.html#cvs): - - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig - -... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): - - $ apt-get source mig - -Please see the Debian [[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. - -## Preparing for the Build - -### ... on Debian systems - -Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: - - # apt-get install build-essential fakeroot - # apt-get build-dep mig - -### ... on non-Debian systems - -Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. - -Additionally, you need to have GNU Mach's header files installed. See -[[mach/gnu_mach/building]] about how to do that, then come back here. - -## Building and Installing - -### ... a _.deb_ file - -Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): - - $ cd mig-1.3.1.99 - -Start the build process: - - $ dpkg-buildpackage -us -uc -b -rfakeroot - -You can then install / distribute the _.deb_ file which will drop out one directory above the current one. - -### [TODO] - -The Mach Interface Generator has to be built in a separate directory: - - $ mkdir mig-build - $ cd mig-build - -Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: - - $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" - -Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: - - $ make all install - -To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: - - PATH=~/gnu/bin:$PATH - export PATH - -If you already have e.g. _~/bin_ in your _$PATH_, you could also create a symbolic link: - - $ ln -s ~/gnu/bin/mig ~/bin/ diff --git a/microkernel/mach/mig/discussion.mdwn b/microkernel/mach/mig/discussion.mdwn deleted file mode 100644 index fdab3a45..00000000 --- a/microkernel/mach/mig/discussion.mdwn +++ /dev/null @@ -1,17 +0,0 @@ -Created - --- [[Main/JoachimNilsson]] - 29 Oct 2002 - -The logo seems very programmer friendly as this web topic is intended. - --- [[Main/GrantBow]] - 15 Nov 2002 - -There's little traffic here and little content. Perhaps we should just remove this web? It seemed like a good idea to create it when we split the others off... - --- [[Main/GrantBow]] - 22 Dec 2002 - -Maybe, but not yet. Let's keep it for a while longer - say, three months. 1st April 2003. If the traffic still is low then we move the Mig topics to the Mach web ... - -...Mig = **Mach** Interface Generator. - --- [[Main/JoachimNilsson]] - 22 Dec 2002 diff --git a/microkernel/mach/mig/gnu_mig.mdwn b/microkernel/mach/mig/gnu_mig.mdwn new file mode 100644 index 00000000..4f5fb5c8 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig.mdwn @@ -0,0 +1,24 @@ +[[meta copyright="Copyright © 2001, 2006, 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]]."]]"""]] + +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]]. + + * [[Building]] - building (and obtaining) GNU MIG + * [[Open_Issues]] diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn new file mode 100644 index 00000000..8b553b6b --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -0,0 +1,73 @@ +# Building the Mach Interface Generator from Source + +If you want to build the Mach Interface Generator yourself instead of just using a pre-built package, follow these instructions. + +## Getting the Source Code + +You can chose between getting the [sources from the developers' +RCS](http://savannah.gnu.org/cvs/?group=hurd): + + $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig + +... or (if you are working on a Debian system) the ones that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): + + $ apt-get source mig + +Please see 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. + +## Preparing for the Build + +### ... on Debian systems + +Building the Mach Interface Generator requires the _build-essential_ and _fakeroot_ packages, their dependencies and additional packages that are specified by the source mig package: + + # apt-get install build-essential fakeroot + # apt-get build-dep mig + +### ... on non-Debian systems + +Building the Mach Interface Generator requires a C compiler, a standard C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. + +Additionally, you need to have GNU Mach's header files installed. See +[[mach/gnu_mach/building]] about how to do that, then come back here. + +## Building and Installing + +### ... a _.deb_ file + +Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): + + $ cd mig-1.3.1.99 + +Start the build process: + + $ dpkg-buildpackage -us -uc -b -rfakeroot + +You can then install / distribute the _.deb_ file which will drop out one directory above the current one. + +### [TODO] + +The Mach Interface Generator has to be built in a separate directory: + + $ mkdir mig-build + $ cd mig-build + +Find the root directory where you installed GNU Mach's header files and where you now intend to install the Mach Interface Generator (_~/gnu_) and the path to your Mach Interface Generator sources (\_[...]/mig) and configure it: + + $ GNU=~/gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include [...]/mig/configure --prefix="$GNU" + +Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: + + $ make all install + +To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: + + PATH=~/gnu/bin:$PATH + export PATH + +If you already have e.g. _~/bin_ in your _$PATH_, you could also create a symbolic link: + + $ ln -s ~/gnu/bin/mig ~/bin/ diff --git a/microkernel/mach/mig/gnu_mig/open_issues.mdwn b/microkernel/mach/mig/gnu_mig/open_issues.mdwn new file mode 100644 index 00000000..7a6233da --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/open_issues.mdwn @@ -0,0 +1,20 @@ +[[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]]."]]"""]] + +[[meta title="Open Issues"]] + +This is a dumping ground for open issues for GNU MIG. + +[[inline +pages="microkernel/mach/mig/gnu_mig/open_issues/* and !*/discussion" +show=0 +actions=yes +rootpage="microkernel/mach/mig/gnu_mig/open_issues" +postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn new file mode 100644 index 00000000..93347759 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/open_issues/duplicate_inclusion_guards.mdwn @@ -0,0 +1,14 @@ +[[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]]."]]"""]] + +E.g., both `/usr/include/hurd/process.h` and +`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion +guard. This leads to problems when both are needed, as is the case in +[[GDB]]'s `gdb/gnu-nat.c`. diff --git a/microkernel/mach/mig/open_issues.mdwn b/microkernel/mach/mig/open_issues.mdwn deleted file mode 100644 index 2d870695..00000000 --- a/microkernel/mach/mig/open_issues.mdwn +++ /dev/null @@ -1,19 +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]]."]]"""]] - -[[meta title="Open Issues"]] - -This is a dumping ground for open issues for GNU MIG. - -[[inline -pages="microkernel/mach/mig/open_issues/* and !*/discussion" -show=0 -actions=yes -rootpage="microkernel/mach/mig/open_issues" postformtext="Add a new item titled:"]] diff --git a/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn b/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.mdwn deleted file mode 100644 index 93347759..00000000 --- a/microkernel/mach/mig/open_issues/duplicate_inclusion_guards.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]]."]]"""]] - -E.g., both `/usr/include/hurd/process.h` and -`/usr/include/hurd/process_request.h` use `_process_user_` as an inclusion -guard. This leads to problems when both are needed, as is the case in -[[GDB]]'s `gdb/gnu-nat.c`. diff --git a/mig-download.html b/mig-download.html deleted file mode 100644 index efbf1359..00000000 --- a/mig-download.html +++ /dev/null @@ -1,167 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Latest Release

-

-The latest release of MIG is version 1.3, 2002-03-08. However, it is -recommended that you use the version in CVS instead, as we are only a few steps -before we'll do another release from there. - - - -

CVS repository

-

-The MIG source code is managed in the version control system CVS. You can check out the CVS -repository through anonymous CVS over SSH with the following -instruction set. When prompted for a password for anoncvs, -simply press the Enter key. - -

-Source tree: - 
-cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig - -

Updates from within the module's directory do not need the -d parameter. - -

For the full details, read the savannah page. - -

Browsing the code

-

-You can also browse the CVS -repository of MIG with your web browser. The web pages are -generated dynamically at the time you request them and are always up -to date. -

-There is also a cross referenced -database of the Hurd, GNU Mach, MIG, and the GNU C library sources -online for you to browse. It provides better searching and browsing -facilities than the online CVS repository, but it is not always up to -date and does not contain history information. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. -

- -
- -[ - - - English -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2007 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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/mig.html b/mig.html deleted file mode 100644 index 49e19a37..00000000 --- a/mig.html +++ /dev/null @@ -1,125 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| es -| he -| pl -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

-

Table of Contents

- -

-

- -

Introduction to GNU MIG

-

-GNU MIG is the GNU distribution of the Mach 3.0 interface generator `MIG', as -maintained by the GNU Hurd developers for the GNU project. -

-The interface generator produces stub code from interface definition -(.defs) files. The stub code makes it easy to implement -and use Mach interfaces as remote procedure calls (RPC). -

-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. - -

Status of the project

-

-MIG 1.3 was released in March 2002, and features compatibility with -OSF Mach. -

- -
- -[ - - - en -| es -| he -| pl -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2006 Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/sidebar.mdwn b/sidebar.mdwn index a368c6c3..6a132e6d 100644 --- a/sidebar.mdwn +++ b/sidebar.mdwn @@ -11,25 +11,27 @@ is included in the section entitled Welcome to... [[img hurd/logo/boxes-redrawn.png link=/hurd/logo]] ... the GNU Hurd! -* **[[Home|/index]]** -* **[[Community]]** -* **[[Documentation]]** -* **[[Hurd/Getting_Help]]** + * **[[Home|/index]]** + * **[[Community]]** + * **[[Documentation]]** + * **[[Hurd/Getting_Help]]** --- -* **[[Hurd]]**[[if test="destpage(hurd*)" then=" - * *[[Hurd/Documentation]]* - * *[[hurd/Running]]*"]] -* **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" - * *[[microkernel/mach/GNU_Mach]]* - * *[[microkernel/mach/Documentation]]*"]] + * **[[Hurd]]**[[if test="destpage(hurd*)" then=" + * *[[Hurd/Documentation]]* + * *[[hurd/Running]]*"]] + * **[[microkernel/Mach]]**[[if test="destpage(microkernel/mach*)" then=" + * *[[microkernel/mach/Documentation]]* + * *[[microkernel/mach/GNU_Mach]]*"]] + * *[[microkernel/mach/MIG]]*[[if test="destpage(microkernel/mach/mig*)" then=" + * [[microkernel/mach/mig/GNU_MIG]]"]] --- -* **[[Debian_GNU/Hurd|hurd/running/debian]]** -* **[[GNU_system|hurd/running/gnu]]** + * **[[Debian_GNU/Hurd|hurd/running/debian]]** + * **[[GNU_system|hurd/running/gnu]]** --- -* **[[HurdNG|hurd/ng]]** + * **[[HurdNG|hurd/ng]]** -- cgit v1.2.3 From 051c71afa05196ac66d7912e27063962478c599d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 08:56:44 +0100 Subject: Integrate GNU Mach HTML pages. --- gnumach-download.html | 189 -------------------------------- gnumach-install.html | 131 ---------------------- gnumach.html | 180 ------------------------------ microkernel/mach/gnu_mach.mdwn | 67 +++++++++-- microkernel/mach/gnu_mach/building.mdwn | 2 +- 5 files changed, 59 insertions(+), 510 deletions(-) delete mode 100644 gnumach-download.html delete mode 100644 gnumach-install.html delete mode 100644 gnumach.html (limited to 'microkernel/mach') diff --git a/gnumach-download.html b/gnumach-download.html deleted file mode 100644 index fa1990d9..00000000 --- a/gnumach-download.html +++ /dev/null @@ -1,189 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| es -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Latest Release

-

-The latest release of GNU Mach is version 1.3, 2002-05-28. However, it is -recommended that you use the version in CVS instead, the -gnumach-1-branch to be exact, as we are only a few steps before we'll -do another release from that branch. - - - -

CVS repository

-

-The GNU Mach source code is managed in the version control system CVS. You can check out the CVS repository -with the following instruction set. - -

-Source tree: -
-cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co gnumach -

-Use to following to get the GNU Mach 1 branch: -
-cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach - -

Updates from within the module's directory do not need the -d parameter. - -

For the full details, read the Savannah page. - -

Browsing the code

-

-You can also browse the CVS -repository of GNU Mach with your web browser. The web pages are -generated dynamically at the time you request them and are always up -to date. -

-There is also a cross referenced -database of the Hurd, GNU Mach, MIG, and the GNU C library sources -online for you to browse. It provides better searching and browsing -facilities than the online CVS repository, but it is not always up to -date and does not contain history information. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. -

- -
- -[ - - - en -| es -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2007 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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/gnumach-install.html b/gnumach-install.html deleted file mode 100644 index c42f2404..00000000 --- a/gnumach-install.html +++ /dev/null @@ -1,131 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Latest version

-

-The last stable version of GNU Mach is 1.3, but it is recommended that -you use the version in -CVS instead, the gnumach-1-branch to be exact, as we are only a -few steps before we'll do another release from that branch. - -

Installation instructions

-

-GNU Mach can be compiled or cross-compiled easily. The only package -you are not likely to have installed already is MIG, the Mach -interface generator. If you cross-compile gnumach, you need a -cross-MIG for your architecture. You also need the static version of -the C library for your host architecture, as some functions are taken -directly from it. We recommend that you use the GNU C library, other C libraries -have not been tested and might not work. After you have followed the -installation instructions in the package and the reference manual, you -should end up with a kernel binary where your boot loader can find it. - -

Booting GNU Mach

-

-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, which supports a broad range of operating systems including -GNU/Hurd. -

- -
- -[ - - - English -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2007 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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/gnumach.html b/gnumach.html deleted file mode 100644 index 4ba0e9f7..00000000 --- a/gnumach.html +++ /dev/null @@ -1,180 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Hebrew -| Polish -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

-

Table of Contents

- -

-

- -

Introduction to GNU Mach

-

-GNU Mach is the microkernel of the GNU system. A microkernel provides -only a limited functionality, just enough abstraction on top of the -hardware to run the rest of the operating system in user space. The -GNU Hurd servers and the GNU C library implement the POSIX compatible -base of the GNU system on top of the microkernel architecture provided -by Mach. -

-Currently, GNU Mach runs on IA32 machines. GNU Mach should, and -probably will, be ported to other hardware architectures in the -future. Mach was ported to many operating systems in the past. -

-GNU Mach is maintained by the Hurd developers for the GNU project. If -you need help with GNU Mach or want to contribute to the development -of the microkernel, you should contact the Hurd people. - -

Advantages of GNU Mach

-GNU Mach is not the most advanced microkernel known to the planet, nor -is it the fastest or smallest, but it has a rich set of interfaces and -some features which make it useful as the base of the Hurd system. -
-
it's free software
-
-Anybody can use, modify, and redistribute it under the terms of the -GNU General Public License (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. -
-
- -

Status of the project

-

-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, and so a broad range of common hardware is supported. -

-However, the Linux device drivers have been improved greatly since the -2.0.x version, and a new version of GNU Mach based on the OSKit -library is being worked on, which uses newer drivers and in general -has cleaner machine specific support code. -

- -
- -[ - - - English -| Hebrew -| Polish -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn index d45549f5..cdb43a6f 100644 --- a/microkernel/mach/gnu_mach.mdwn +++ b/microkernel/mach/gnu_mach.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[meta copyright="Copyright © 2001, 2002, 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 @@ -8,9 +9,10 @@ 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 currently used by the GNU [[Hurd]]. +GNU Mach is the microkernel that the [[GNU_Hurd|hurd]] system is based on. -GNU Mach remains compatible with [[Mach]] 3.0. +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. @@ -20,11 +22,58 @@ GNU Mach runs on x86 machines. See the [[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 -* [[Building]] -* [[Debugging]] -* [[Boot_Trace]] -* [[Projects]] - * [[Rules]] - * [[Open_Issues]] + * [[Building]] + * [[Debugging]] + * [[Boot_Trace]] + * [[Projects]] + * [[Rules]] + * [[Open_Issues]] diff --git a/microkernel/mach/gnu_mach/building.mdwn b/microkernel/mach/gnu_mach/building.mdwn index 073c68a3..014d3e87 100644 --- a/microkernel/mach/gnu_mach/building.mdwn +++ b/microkernel/mach/gnu_mach/building.mdwn @@ -13,7 +13,7 @@ enabled) is around 50 MiB. ### Developers's RCS -See [here](http://www.gnu.org/software/hurd/gnumach-download.html#cvs). +See . $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co -r gnumach-1-branch gnumach -- cgit v1.2.3 From 24e7f01d6e6322e9d98412076dcf3f4d98196bb0 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 6 Nov 2008 11:37:33 +0100 Subject: Integrate auth.html, hurd-paper.html, hurd-talk.html. Move content from devel.html, docs.html. --- auth.html | 248 ----- contributing.mdwn | 10 +- devel.html | 159 ---- docs.html | 302 ------ documentation.mdwn | 16 +- hurd-paper.html | 812 ---------------- hurd-talk.html | 1151 ----------------------- hurd.mdwn | 2 - hurd/authentication.mdwn | 2 +- hurd/critique.mdwn | 4 +- hurd/documentation.mdwn | 48 +- hurd/documentation/auth.html | 168 ++++ hurd/documentation/hurd-paper.html | 760 +++++++++++++++ hurd/documentation/hurd-talk.html | 1061 +++++++++++++++++++++ hurd/hurd_hacking_guide.mdwn | 16 +- hurd/ng/position_paper.mdwn | 9 +- hurd/reference_manual.mdwn | 18 + hurd/running/distrib.mdwn | 2 +- hurd/running/gnu/universal_package_manager.mdwn | 2 +- hurd/translator.mdwn | 1 + hurd/translator/auth.mdwn | 13 + microkernel/faq/multiserver_microkernel.mdwn | 4 +- microkernel/mach/documentation.mdwn | 18 +- microkernel/mach/gnu_mach.mdwn | 1 + microkernel/mach/gnu_mach/reference_manual.mdwn | 26 + microkernel/mach/mig/documentation.mdwn | 3 +- 26 files changed, 2146 insertions(+), 2710 deletions(-) delete mode 100644 auth.html delete mode 100644 devel.html delete mode 100644 docs.html delete mode 100644 hurd-paper.html delete mode 100644 hurd-talk.html create mode 100644 hurd/documentation/auth.html create mode 100644 hurd/documentation/hurd-paper.html create mode 100644 hurd/documentation/hurd-talk.html create mode 100644 hurd/reference_manual.mdwn create mode 100644 hurd/translator/auth.mdwn create mode 100644 microkernel/mach/gnu_mach/reference_manual.mdwn (limited to 'microkernel/mach') diff --git a/auth.html b/auth.html deleted file mode 100644 index 676442ee..00000000 --- a/auth.html +++ /dev/null @@ -1,248 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
-

 -
-

Table of Contents

- -
- -

Introduction

-

-In this text, which mostly resembles the talk I gave at Libre Software -Meeting 2002 in Bordeaux, I will describe what the auth server does, -why it is so important and which cool things you can do with it, both -on the programming and the user side. I will also describe related -programs like the password and fakeauth servers. Note that this text -is targeted at programmers who want to understand the auth mechanism -in detail and are already familiar with concepts like Remote Procedure -Calls (RPCs) as well as the way User- and Group-IDs are used in the -POSIX world. - -

-The auth server is a very small server, therefore it gives a useful -example when you want to learn how a server typically looks like. One -reason why it is so small is that the auth interface, which it -implements, consists of only four RPCs. You can find the interface in -hurd/hurd/auth.defs and the server itself in hurd/auth/. - -

How IDs are represented and used

-

-Each process holds (usually) one port to auth (an auth_t in C source, -which actually is a mach_port_t, of course). The purpose of auth is -to manage User-IDs and Group-IDs, which is the reason why users often -will have no choice but to make use of the systems main auth server, -which does not listen on /servers/auth; instead you inherit a port to -auth from your parent process. Each such port is (internally in the -auth server) associated with a set of effective User- and Group-IDs as -well as a set of available User- and Group-IDs. So we have four sets -of IDs in total. The available IDs can be turned into corresponding -effective IDs at any time. - -

-When you send an auth_getids RPC on the port you hold, you will get -information about which IDs are associated with it, so you can figure -out which permissions you have. But how will a server know that you -have these permissions and therefore know which actions (e.g. writing -into file "foo") it is supposed to do on your behalf and which not? -The establishing of a trusted connection to a server works as follows: - -

    -
  1. A user wants a server to know its IDs
    2. -
  2. The user requests a reauthentication from the server
    3. -
  3. In this request the user will include a port
    4. -
  4. Both will hand this port to auth
    5. -
  5. The user uses auth_user_authenticate
    6. -
  6. The server uses auth_server_authenticate
    7. -
  7. The server also passes a new port to auth
    8. -
  8. auth matches these two requests
    9. -
  9. The user gets the new port from auth
    10. -
  10. The server learns about the IDs of the user
    11. -
  11. The user uses the new port for further communication
    12. -
- -

-We have different RPCs for users and servers because what we pass and -what we get back differs for them: Users get a port, and servers get -the sets of IDs, and have to specify the port which the user will get. - -

-It is interesting to note that auth can match the requests by -comparing two integers, because when you get the same port from two -people, you will have the same mach_port_t (which is nothing but an -integer). - -

-All of this of course only works if they use the same auth server, -which is why I said often you have no choice other than to use the -one main auth server. But this is no serious restriction, as the auth server has -almost no functionality one might want to replace. In fact, there is -one replacement for the default auth implementation, but more on that -later. - -

POSIX and beyond

-

-Before we examine what is possible with this design, let us take a -short look at how the POSIX semantics are implemented on top of this -design. When a program that comes out of POSIX-land asks for its own -effective User- or Group-ID, we will tell it about the first of the -effective IDs. In the same sense, the POSIX real User- or Group-ID is -the first available ID and the POSIX saved User- or Group-ID is the -second available ID, which is why you have the same ID two times in -the available IDs when you log into your GNU/Hurd machine (you can -figure out which IDs you have with the program "ids", that basically -just does an auth_getauth RPC). When you lack one of those IDs (for -example when you have no effective Group-ID), a POSIX program asking -for this particular information will get "-1" as the ID. - -

-But as you can imagine, we can do more than what POSIX specifies. Fox -example, we can modify our permissions. This is always done with the -auth_makeauth RPC. In this RPC, you specify the IDs that should be -associated with the new port. All of these IDs must be associated -with either the port where the RPC is sent to or one of the additional -ports you can specify; an exception is the superuser root, which is -allowed to creat ports that are associated with arbitrary IDs. -Hereby you can convert available into effective IDs. - -

-This opens the door to a bunch of nice features. For example, we have -the addauth program in the Hurd, which makes it possible to add an ID -to either a single process or a group of processes if you hold the ID or know the -appropriate password, and there is a corresponding rmauth program that -removes an ID. So when you are working on your computer with GNU -Emacs and want to edit a system configuration file, you switch to -Emacs' shell-mode, do an "addauth root", enter the password, edit the -file, and when you are done switch back to shell-mode and do "rmauth -root". These programs have some interesting options, and there are -various other programs, for setting the complete list of IDs (setauth) -and so on. - -

Related servers

-

-Finally, I want to explain two servers which are related to auth. The -first is the password server, which listens on /servers/password. If -you pass to it a User- or Group-ID and the correct password for it, it -will return a port to auth to you which is associated with the ID you -passed to it. It can create such a port because it is running as -root. So let us assume you are an FTP server process. You will start -as root, because you want to use port 21 (in this case, "port" does -not refer to a mach_port_t, of course). But then, you can drop all -your permissions so that you run without any ID. This makes it far -less dangerous to communicate with yet unknown users over the -network. But when someone now hands a username and password to you, -you can ask the password server for a new auth port. The password -server will check the data you pass to it, for example by looking into -/etc/shadow, and if it is valid, it will ask the auth server for a new -port. It receives this port from auth and then passes it on to you. -So you have raised your permissions. (And for the very curious: Yes, -we are well aware of the differences between this concept and -capabilities; and we also do have some kinds of capabilities in -various parts of the Hurd.) - -

-My second example is the fakeauth server. It also implements the auth -protocol. It is the part of the fakeroot implementation that gives a -process the impression that it runs as root, even if it doesn't. So -when the process asks fakeauth about its own IDs, fakeauth will tell -the process that it runs as root. But when the process wants to make -use of the authentication protocol described earlier in this text, -fakeauth will forward the request to its own auth server, which will -usually be the systems main auth server, which will then be able to -match the auth_*_authenticate requests. So what fakeauth does is -acting as a proxy auth server that gives someone the impression to run -as root, while not modifying what that one is allowed to do. - -

-At this point, I have said at least most of what can be said about the -auth server and the protocol it implements, so I will finish by saying -that it might be an interesting task (for you) to modify some existing -software to take advantage of the features I described here. - -

- -
- -[ - English -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2002 Free Software Foundation, Inc., -59 Temple Place - Suite 330, Boston, MA 02111, USA -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/contributing.mdwn b/contributing.mdwn index 698d03b3..f1003389 100644 --- a/contributing.mdwn +++ b/contributing.mdwn @@ -52,7 +52,7 @@ is another possibility, see the page about [[running_a_Hurd_system|hurd/running]] for the full story. Then you can either play around and eventually strive to do something -useful or -- if you want -- ask us to assign something to you, depending +useful or -- if you want -- [[ask_us|contact_us]] to assign something to you, depending on the skills you have and the resources you intend to invest. Please spend some time with thinking about the items in this [[questionnaire]]. @@ -62,10 +62,10 @@ system, e.g., [[microkernels_for_beginners|microkernel/for_beginners]]. Until you can do the basic exercises listed there, you won't be able to significantly contribute to the Hurd. -For more reading resources, please see these web pages, and also -, - for links to a bunch of documents, -and in general. +For more reading resources, please see these web pages, for example, +[[Hurd_documentation|hurd/documentation]] and +[[Mach_documentation|microkernel/mach/documentation]] for links to a bunch of +documents. ### Porting Packages diff --git a/devel.html b/devel.html deleted file mode 100644 index 2a31f959..00000000 --- a/devel.html +++ /dev/null @@ -1,159 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - en -| eo -| es -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Contributing

-

-If you want to contribute to the Hurd, you should first install and -use it for a while, to become familiar with its features and design. -To join the development team, subscribe to the -Bug-Hurd -<bug-hurd@gnu.org> -mailing list, which is also the place where you can announce your -intentions, make your proposals and send in your patches. -(You can also send mail there without being subscribed to the list.) -

-There is also the -Hurd-devel-readers -mailing list. It is the read-only version of Hurd-devel, an internal -low-volume list restricted to the core developers of the Hurd. If you -want to follow up on the discussion of the Hurd experts, please reply -to the Bug-hurd mailing list. You can also follow the Hurd-devel -mailing list by browsing the web-based archive of -Hurd-devel. - -

Machinery: getting access to a -system

-

-There are essentially two possibilities: either you install the GNU/Hurd on a -system (see here) or if you don't -have a system to install it on, you can be provided with a shell account. See -this wiki page -for details. - -

Tasks

-

-Developing an operating system is a huge job, with a lot of different -things to do. To be able to keep track of issues, we use a -

-There is also an older (but still valid) list of specific items in the -task file -and in the -TODO file -of the Hurd source repository. - -
- -
- -[ - - - en -| eo -| es -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2006, 2007 -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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/docs.html b/docs.html deleted file mode 100644 index 9c3a43f1..00000000 --- a/docs.html +++ /dev/null @@ -1,302 +0,0 @@ - - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -| Esperanto -| Spanish -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
- -

Introductory material, papers and other -informational documents

-

-

- -

Frequently asked questions

-

-Please check out the -Frequently -Asked Questions about the GNU Hurd (33k characters) and their -answers, which cover most issues a new user will be confronted with. -

-This document is available in several languages: -

- -

Wiki

-

A wiki is available for -collecting ideas and reciepes. Fell free -to contribute! - -

Some topics: - -

- - -

Reference manuals

- -
    - -
  • -

    -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. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. Be sure to get the -GNU Mach 1 branch when you intend to work on the manual. You -can then find the manual's sources in the doc/ directory. Please -submit any modifications to <bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
  • -

    -The GNU Hurd Reference Manual documents the architecture, the usage -and the programming of the GNU Hurd. At the moment, the manual is -quite incomplete. -

    -Available Formats: -

    -

    -If you want to work on the manual, you're advised to make a checkout of the source tree. You can then find the manual's -sources in the doc/ directory. Please submit any modifications to -<bug-hurd@gnu.org> (if possible in -unidiff format, as produced by diff -u). - -

    • - -
- -
- -
- -[ - - - English -| Esperanto -| Spanish -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001, 2002, 2003, 2004, 2005, 2006, 2007 -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. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/documentation.mdwn b/documentation.mdwn index 45bb5ffc..4e4b4b23 100644 --- a/documentation.mdwn +++ b/documentation.mdwn @@ -8,21 +8,13 @@ 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]]."]]"""]] -# General +Documentation for... - * [GNU Hurd Documentation](http://www.gnu.org/software/hurd/docs.html) + * [[GNU_Hurd|hurd/documentation]] + * [[Mach|microkernel/mach/documentation]] -# Introductory Material - -## External - - * [*Examining the Legendary HURD - Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), - an article by David Chisnall. - - Also covers a bit of GNU's and the Hurd's history, fundamental techniques - applied, comparisions to other systems. + * [[MIG|microkernel/mach/mig/documentation]] # [[Unix]] Programming diff --git a/hurd-paper.html b/hurd-paper.html deleted file mode 100644 index bb49829c..00000000 --- a/hurd-paper.html +++ /dev/null @@ -1,812 +0,0 @@ - - - -Towards a New Strategy of OS Design - - - -

Towards a New Strategy of OS Design

- [image of a Hurd Metafont Logo] (jpeg 10k) -(jpeg 20k) -no gifs due to patent problems -
-
-[ - - - English -| Hebrew -| Turkish -] - -

-This article explains why FSF is developing a new operating system named the -Hurd, which will be a foundation of the whole GNU system. -The Hurd is built -on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and -message-passing facilities. -The GNU C Library will provide the Unix system -call interface, and will call the Hurd for needed services it can't provide -itself. -The design and implementation of the Hurd is being lead by Michael -Bushnell, with assistance from Richard Stallman, Roland McGrath, -Jan Brittenson, and others. - -

Part 1: A More Usable Approach to OS Design

-

-The fundamental purpose of an operating system (OS) is to enable a variety of -programs to share a single computer efficiently and productively. -This -demands memory protection, preemptively scheduled timesharing, coordinated -access to I/O peripherals, and other services. -In addition, an OS can allow -several users to share a computer. -In this case, efficiency demands services -that protect users from harming each other, enable them to share without -prior arrangement, and mediate access to physical devices. -

-On today's computer systems, programmers usually implement these goals -through a large program called the kernel. -Since this program must be -accessible to all user programs, it is the natural place to add functionality -to the system. -Since the only model for process interaction is that of -specific, individual services provided by the kernel, no one creates other -places to add functionality. -As time goes by, more and more is added to the -kernel. -

-A traditional system allows users to add components to a kernel only if they -both understand most of it and have a privileged status within the system. -Testing new components requires a much more painful edit-compile-debug cycle -than testing other programs. -It cannot be done while others are using the -system. -Bugs usually cause fatal system crashes, further disrupting others' -use of the system. -The entire kernel is usually non-pageable. -(There are -systems with pageable kernels, but deciding what can be paged is difficult -and error prone. -Usually the mechanisms are complex, making them difficult -to use even when adding simple extensions.) -

-Because of these restrictions, functionality which properly belongs -behind -the wall of a traditional kernel is usually left out of systems unless it is -absolutely mandatory. -Many good ideas, best done with an open/read/write -interface cannot be implemented because of the problems inherent in the -monolithic nature of a traditional system. -Further, even among those with -the endurance to implement new ideas, only those who are privileged users of -their computers can do so. -The software copyright system darkens the mire by -preventing unlicensed people from even reading the kernel source. -

-Some systems have tried to address these difficulties. -Smalltalk-80 and -the Lisp Machine both represented one method of getting around the problem. -System code is not distinguished from user code; all of the system is -accessible to the user and can be changed as need be. -Both systems were -built around languages that facilitated such easy replacement and extension, -and were moderately successful. -But they both were fairly poor at insulating -users and programs from each other, failing one of the principal goals of OS -design. -

-Most projects that use the Mach 3.0 kernel carry on the hard-to-change -tradition of OS design. -The internal structure is different, but the same -heavy barrier between user and system remains. -The single-servers, while -fairly easy to construct, inherit all the deficiencies of the monolithic -kernels. -

-A multi-server divides the kernel functionality up into logical blocks with -well-defined interfaces. -Properly done, it is easier to make changes and add -functionality. -So most multi-server projects do somewhat better. -Much more -of the system is pageable. -You can debug the system more easily. -You can -test new system components without interfering with other users. -But the -wall between user and system remains; no user can cross it without special -privilege. -

-The GNU Hurd, by contrast, is designed to make the area of -system -code as -limited as possible. -Programs are required to communicate only with a few -essential parts of the kernel; the rest of the system is replaceable -dynamically. -Users can use whatever parts of the remainder of the system -they want, and can easily add components themselves for other users to take -advantage of. -No mutual trust need exist in advance for users to use each -other's services, nor does the system become vulnerable by trusting the -services of arbitrary users. -

-This has been done by identifying those system components which users -must -use in order to communicate with each other. -One of these is responsible for -identifying users' identities and is called the - -authentication server. - -In -order to establish each other's identities, programs must communicate, each -with an authentication server they trust. -Another component establishes -control over system components by the superuser, provides global bookkeeping -operations, and is called the - -process server. - -

-Not all user programs need to communicate with the process server; it is only -necessary for programs which require its services. -Likewise, the -authentication server is only necessary for programs that wish to communicate -their identity to another. -None of the remaining services carry any special -status; not the network implementation, the filesystems, the program -execution mechanism (including setuid), or any others. - -

The Translator Mechanism

-

-The Hurd uses Mach ports primarily as methods for communicating between users -and servers. -(A Mach port is a communication point on a Mach task where -messages are sent and received.) Each port implements a particular set of -protocols, representing operations that can be undertaken on the underlying -object represented by the port. -Some of the protocols specified by the Hurd -are the I/O protocol, used for generic I/O operations; the file protocol, -used for filesystem operations; the socket protocol, used for network -operations; and the process protocol, used for manipulating processes et al. -

-Most servers are accessed by opening files. -Normally, when you open a file, -you create a port associated with that file that is owned by the server -that owns the directory containing the file. -For example, a disk-based -filesystem will normally serve a large number of ports, each of which -represents an open file or directory. -When a file is opened, the server -creates a new port, associates it with the file, and returns the port to the -calling program. -

-However, a file can have a -translator -associated with it. -In this case, -rather than return its own port which refers to the contents of the file, the -server executes a translator program associated with that file. -This -translator is given a port to the actual contents of the file, and is then -asked to return a port to the original user to complete the open operation. -

-This mechanism is used for -mount -by having a translator associated with -each mount point. -When a program opens the mount point, the translator (in -this case, a program which understands the disk format of the mounted -filesystem) is executed and returns a port to the program. -After the -translator is started, it need not be run again unless it dies; the parent -filesystem retains a port to the translator to use in further requests. -

-The owner of a file can associate a translator with it without special -permission. -This means that any program can be specified as a translator. -Obviously the system will not work properly if the translator does not -implement the file protocol correctly. -However, the Hurd is constructed so -that the worst possible consequence is an interruptible hang. -

-One way to use translators is to access hierarchically structured data using -the file protocol. -For example, all the complexity of the user interface to -the -ftp -program is removed. -Users need only know that a particular -directory represents FTP and can use all the standard file manipulation -commands (e.g -ls -or -cp) -to access the remote system, rather than learning -a new set. -Similarly, a simple translator could ease the complexity of -tar -or -gzip. -(Such transparent access would have some added cost, but it would -be convenient.) - -

Generic Services

-

-With translators, the filesystem can act as a rendezvous for interfaces which -are not similar to files. -Consider a service which implements some version -of the X protocol, using Mach messages as an underlying transport. -For each -X display, a file can be created with the appropriate program as its -translator. -X clients would open that file. -At that point, few file -operations would be useful (read and write, for example, would be useless), -but new operations ( -XCreateWindow -or -XDrawText) -might become meaningful. -In this case, the filesystem protocol is used only to manipulate -characteristics of the node used for the rendezvous. -The node need not -support I/O operations, though it should reply to any such messages with a -message_not_understood -return code. -

-This translator technique is used to contact most of the services in the Hurd -that are not structured like hierarchical filesystems. -For example, the -password server, which hands out authorization tags in exchange for -passwords, is contacted this way. -Network protocol servers are also -contacted in this fashion. -Roland McGrath thought up this use of translators. - -

Clever Filesystem Pictures

-

-In the Hurd, translators can also be used to present a filesystem-like view -of another part of the filesystem, with some semantics changed. -For example, -it would be nice to have a filesystem that cannot itself be changed, but -nonetheless records changed versions of its files elsewhere. -(This could be -useful for source code management.) -

-The Hurd will have a translator which creates a directory which is a -conceptual union of other directories, with collision resolution rules of -various sorts. -This can be used to present a single directory to users that -contains all the programs they would want to execute. -There are other useful -variations on this theme. - -

What The User Can Do

-

-No translator gains extra privilege by virtue of being hooked into the -filesystem. -Translators run with the uid of the owner of the file being -translated, and can only be set or changed by that owner. -The I/O and -filesystem protocols are carefully designed to allow their use by mutually -untrusting clients and servers. -Indeed, translators are just ordinary -programs. -The GNU C library has a variety of facilities to make common sorts -of translators easier to write. -

-Some translators may need special privileges, such as the password server or -translators which allow setuid execution. -These translators could be run by -anyone, but only if they are set on a root-owned node would they be able to -provide all their services successfully. -This is analogous to letting any -user call the -reboot -system call, but only honoring it if that user is root. - -

Why This Is So Different

-

-What this design provides is completely novel to the Unix world. -Until now, -OSs have kept huge portions of their functionality in the realm of system -code, thus preventing its modification and extension except in extreme need. -Users cannot replace parts of the system in their programs no matter how much -easier that would make their task, and system managers are loath to install -random tweaks off the net into their kernels. -

-In the Hurd, users can change almost all of the things that are decided for -them in advance by traditional systems. -In combination with the tremendous -control given by the Mach kernel over task address spaces and properties, the -Hurd provides a system in which users will, for the first time, be able to -replace parts of the system they dislike, without disrupting other users. -

-Most Mach-based OSs to date have mostly implemented a wider set of the - -same old - -Unix semantics in a new environment. -In contrast, GNU is extending -those semantics to allow users to improve, bypass, or replace them. - - -

Part 2: A Look at Some of the Hurd's Beasts

-

The Authentication Server

-

-One of the Hurd's more central servers is the authentication server. -Each -port to this server identifies a user and is associated by this server with -an -id block. -Each id block contains sets of user and group ids. -Either -set may be empty. -This server is not the same as the password server -referred to above. -

-The authentication server exports three services. -First, it provides simple -boolean operations on authentication ports: given two authentication ports, -this server will provide a third port representing the union of the two sets -of uids and gids. -Second, this server allows any user with a uid of zero to -create an arbitrary authentication port. -Finally, this server provides RPCs -(Remote Procedure Calls between different programs and possibly different -hosts) which allow mutually untrusting clients and servers to establish their -identities and pass initial information on each other. -This is crucial to -the security of the filesystem and I/O protocols. -

-Any user could write a program which implements the authentication protocol; -this does not violate the system's security. -When a service needs to -authenticate a user, it communicates with its trusted authentication server. -If that user is using a different authentication server, the transaction will -fail and the server can refuse to communicate further. -Because, in effect, -this forces all programs on the system to use the same authentication server, -we have designed its interface to make any safe operation possible, and to -include no extraneous operations. -(This is why there is a separate password -server.) -

The Process Server

-

-The process server acts as an information categorization repository. -There -are four main services supported by this server. -First, the process server -keeps track of generic host-level information not handled by the Mach kernel. -For example, the hostname, the hostid, and the system version are maintained -by the process server. -Second, this server maintains the Posix notions of -sessions and process groups, to help out programs that wish to use Posix -features. -

-Third, the process server maintains a one-to-one mapping between Mach tasks -and Hurd processes. -Every task is assigned a pid. -Processes can register a -message port with this server, which can then be given out to any program -which requests it. -This server makes no attempt to keep these message ports -private, so user programs are expected to implement whatever security they -need themselves. -(The GNU C Library provides convenient functions for all -this.) Processes can tell the process server their current `argv' and `envp' -values; this server will then provide, on request, these vectors of arguments -and environment. -This is useful for writing -ps-like -programs and also -makes it easier to hide or change this information. -None of these features -are mandatory. -Programs are free to disregard all of this and never register -themselves with the process server at all. -They will, however, still have a -pid assigned. -

-Finally, the process server implements -process collections, -which are used -to collect a number of process message ports at the same time. -Also, -facilities are provided for converting between pids, process server ports, -and Mach task ports, while ensuring the security of the ports managed. -

-It is important to stress that the process server is optional. -Because of -restrictions in Mach, programs must run as root in order to identify all the -tasks in the system. -But given that, multiple process servers could -co-exist, each with their own clients, giving their own model of the -universe. -Those process server features which do not require root privileges -to be implemented could be done as per-user servers. -The user's hands are -not tied. -

Transparent FTP

-

-Transparent FTP is an intriguing idea whose time has come. -The popular -ange-ftp -package available for GNU Emacs makes access to FTP files -virtually transparent to all the Emacs file manipulation functions. -Transparent FTP does the same thing, but in a system wide fashion. -This -server is not yet written; the details remain to be fleshed out, and will -doubtless change with experience. -

-In a BSD kernel, a transparent FTP filesystem would be no harder to write -than in the Hurd. -But mention the idea to a BSD kernel hacker, and the -response is that ``such a thing doesn't belong in the kernel''. -In a sense, -this is correct. -It violates all the layering principles of such systems to -place such things in the kernel. -The unfortunate side effect, however, is -that the design methodology (which is based on preventing users from changing -things they don't like) is being used to prevent system designers from making -things better. -(Recent BSD kernels make it possible to write a user program -that provides transparent FTP. -An example is -alex, -but it needs to run -with full root privileges.) -

-In the Hurd, there are no obstacles to doing transparent FTP. -A translator -will be provided for the node -/ftp. -The contents of -/ftp -will probably -not be directly listable, though further subdirectories will be. -There will -be a variety of possible formats. -For example, to access files on uunet, one -could - -cd /ftp/ftp.uu.net:anonymous:mib@gnu. - -Or to access files on a remote -account, one might - -cd /ftp/gnu.org:mib:passwd. - -Parts of this -command could be left out and the transparent FTP program would read them -from a user's -.netrc -file. -In the last case, one might just - -cd /ftp/gnu.org; - -when the rest of the data is already in -.netrc. -

-There is no need to do a -cd -first--use any file command. -To find out about -RFC 1097 (the Telnet Subliminal Message Option), just type - -more /ftp/ftp.uu.net/inet/rfc/rfc1097. - -A copy command to a local disk -could be used if the RFC would be read frequently. -

Filesystems

-

-Ordinary filesystems are also being implemented. -The initial release of the -Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File -System. -In addition to the ordinary semantics, it will provide means to -record translators, offer thirty-two bit user ids and group ids, and supply a -new id per file, called the -author -of the file, which can be set by the -owner arbitrarily. -In addition, because users in the Hurd can have multiple -uids (or even none), there is an additional set of permission bits providing -access control for - -unknown user - -(no uids) as distinct from - -known but arbitrary user - -(some uids: the existing -world -category of file -permissions). -

-The Network File System protocol will be implemented using 4.4 BSD as a -starting point. -A log-structured filesystem will also be implemented using -the same ideas as in Sprite, but probably not the same format. -A GNU network -file protocol may be designed in time, or NFS may be extended to remove its -deficiencies. -There will also be various ``little'' filesystems, such as the -MS-DOS filesystem, to help people move files between GNU and other OSs. - -

Terminals

-

-An I/O server will provide the terminal semantics of Posix. -The GNU C -Library has features for keeping track of the controlling terminal and for -arranging to have proper job control signals sent at the proper times, as -well as features for obeying keyboard and hangup signals. -

-Programs will be able to insert a terminal driver into communications -channels in a variety of ways. -Servers like -rlogind -will be able to insert -the terminal protocol onto their network communication port. -Pseudo-terminals will not be necessary, though they will be provided for -backward compatibility with older programs. -No programs in GNU will depend -on them. -

-Nothing about a terminal driver is forced upon users. -A terminal driver -allows a user to get at the underlying communications channel easily, to -bypass itself on an as-needed basis or altogether, or to substitute a -different terminal driver-like program. -In the last case, provided the -alternate program implements the necessary interfaces, it will be used by the -C Library exactly as if it were the ordinary terminal driver. -

-Because of this flexibility, the original terminal driver will not provide -complex line editing features, restricting itself to the behavior found in -Posix and BSD. -In time, there will be a -readline-based -terminal driver, -which will provide complex line-editing features for those users who want -them. -

-The terminal driver will probably not provide good support for the -high-volume, rapid data transmission required by UUCP or SLIP. -Those -programs do not need any of its features. -Instead they will be using the -underlying Mach device ports for terminals, which support moving large -amounts of data efficiently. - -

Executing Programs

-

-The implementation of the -execve -call is spread across three programs. -The -library marshals the argument and environment vectors. -It then sends a -message to the file server that holds the file to be executed. -The file -server checks execute permissions and makes whatever changes it desires in -the exec call. -For example, if the file is marked setuid and the fileserver -has the ability, it will change the user identification of the new image. -The file server also decides if programs which had access to the old task -should continue to have access to the new task. -If the file server is -augmenting permissions, or executing an unreadable image, then the exec needs -to take place in a new Mach task to maintain security. -

-After deciding the policy associated with the new image, the filesystem calls -the exec server to load the task. -This server, using the BFD (Binary File -Descriptor) library, loads the image. -BFD supports a large number of object -file formats; almost any supported format will be executable. -This server -also handles scripts starting with -#!, -running them through the indicated -program. -

-The standard exec server also looks at the environment of the new image; if -it contains a variable -EXECSERVERS -then it uses the programs specified -there as exec servers instead of the system default. -(This is, of course, -not done for execs that the file server has requested be kept secure.) -

-The new image starts running in the GNU C Library, which sends a message to -the exec server to get the arguments, environment, umask, current directory, -etc. -None of this additional state is special to the file or exec servers; -if programs wish, they can use it in a different manner than the Library. - -

New Processes

-

-The -fork -call is implemented almost entirely in the GNU C Library. -The new -task is created by Mach kernel calls. -The C Library arranges to have its -image inherited properly. -The new task is registered with the process server -(though this is not mandatory). -The C Library provides vectors of functions -to be called at fork time: one vector to be called before the fork, one after -in the parent, and one after in the child. -(These features should not be -used to replace the normal fork-calling sequence; it is intended for -libraries which need to close ports or clean up before a fork occurs.) -The C -library will implement both fork calls specified by the draft Posix.4a (the -proposed standard dealing with the threads extension to the real-time -extension). -

-Nothing forces the user to create new tasks this way. -If a program wants to -use almost the normal fork, but with some special characteristics, then it -can do so. -Hooks will be provided by the C Library, or the function can even -be completely replaced. -None of this is possible in a traditional Unix -system. - -

Asynchronous Messages

-

-As mentioned above, the process server maintains a - -message port - -for each -task registered with it. -These ports are public, and are used to send -asynchronous messages to the task. -Signals, for example, are sent to the -message port. -The signal message also provides a port as an indication that -the sender should be trusted to send the signal. -The GNU C Library lists a -variety of ports in a table, each of which identifies a set of signals that -can be sent by anyone who possesses that port. -For example, if the user -possesses the task's kernel port, it is allowed to send any signal. -If the -user possesses a special - -terminal id - -port, it is allowed to send the -keyboard and hangup signals. -Users can add arbitrary new entries into the C -library's signal permissions table. -

-When a process's process group changes, the process server will send it a -message indicating the new process group. -In this case, the process server -proves its authority by providing the task's kernel port. -

-The C library also has messages to add and delete uids currently used by the -process. -If new uids are sent to the program, the library adds them to its -current set, and then exchanges messages with all the I/O servers it knows -about, proving to them its new authorization. -Similarly, a message can -delete uids. -In the latter case, the caller must provide the process's task -port. -(You can't harm a process by giving it extra permission, but you can -harm it by taking permission away.) The Hurd will provide user programs to -send these messages to processes. -For example, the -su -command will be able -to cause all the programs in your current login session, to gain a new uid, -rather than spawn a subshell. -

-The C library will allow programs to add asynchronous messages they wish to -recognize, as well as prevent recognition of the standard set. -

Making It Look Like Unix

-

-The C Library will implement all of the calls from BSD and Posix as well as -some obvious extensions to them. -This enables users to replace those calls -they dislike or bypass them entirely, whereas in Unix the calls must be used -``as they come'' with no alternatives possible. -

-In some environments binary compatibility will also be supported. -This works -by building a special version of the library which is then loaded somewhere -in the address space of the process. -(For example, on a VAX, it would be -tucked in above the stack.) A feature of Mach, called system call -redirection, is then used to trap Unix system calls and turn them into jumps -into this special version of the library. -(On almost all machines, the cost -of such a redirection is very small; this is a highly optimized path in Mach. -On a 386 it's about two dozen instructions. -This is little worse than a -simple procedure call.) -

-Many features of Unix, such as signal masks and vectors, are handled -completely by the library. -This makes such features significantly cheaper -than in Unix. -It is now reasonable to use -sigblock -extensively to protect -critical sections, rather than seeking out some other, less expensive method. - -

Network Protocols

-

-The Hurd will have a library that will make it very easy to port 4.4 BSD -protocol stacks into the Hurd. -This will enable operation, virtually for -free, of all the protocols supported by BSD. -Currently, this includes the -CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO -protocols. -

-For optimal performance some work would be necessary to take advantage of -Hurd features that provide for very high speed I/O. -For most protocols this -will require some thought, but not too much time. -The Hurd will run the -TCP/IP protocols as efficiently as possible. -

-As an interesting example of the flexibility of the Hurd design, consider the -case of IP trailers, used extensively in BSD for performance. -While the Hurd -will be willing to send and receive trailers, it will gain fairly little -advantage in doing so because there is no requirement that data be copied and -avoiding copies for page-aligned data is irrelevant. - -

- -[ - - - English -| Hebrew -| Turkish -] - -
- -Return to GNU's home page. -

-FSF & GNU inquiries & questions to -gnu@gnu.org. -Other ways to contact the FSF. -

-Comments on these web pages to -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 1996 Trent Fisher -
-Copyright (C) 1996, 1997, 1998, 2007 Free Software Foundation, Inc., -51 Franklin Street, Fifth Floor, Boston, MA 02110-1301, USA. -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved.

-Updated: - -19 Dec 1998 jonas - -

- - diff --git a/hurd-talk.html b/hurd-talk.html deleted file mode 100644 index 630bbc7d..00000000 --- a/hurd-talk.html +++ /dev/null @@ -1,1151 +0,0 @@ - - - -The GNU Hurd - GNU Project - Free Software Foundation (FSF) - - - - - - - - - - - - -
- [image of the Hurd logo] -[ - - - English -] -
-What's New
- 
-ChangeLogs
- 
-Documentation
-

-GNU Hurd
- 
-Installation
-Getting Help
-Source Code
-Development
-History
- 
-GNU Mach
- 
-Installation
-Source Code
- 
-GNU MIG
- 
-Source Code
- 
-Related Projects -

 -
-

Table of Contents

- -
-

Talk about the Hurd

-

-This talk about the Hurd was written by Marcus Brinkmann for -

    -
  • OSDEM, Brussels, 4. Feb 2001, -
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and -
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. -
- -

Introduction

-

-When we talk about free software, we usually refer to the free -software licenses. We also need relief from software patents, so our -freedom is not restricted by them. But there is a third type of -freedom we need, and that's user freedom. - -

-Expert users don't take a system as it is. They like to change the -configuration, and they want to run the software that works best for -them. That includes window managers as well as your favourite text -editor. But even on a GNU/Linux system consisting only of free -software, you can not easily use the filesystem format, network -protocol or binary format you want without special privileges. In -traditional unix systems, user freedom is severly restricted by the -system administrator. - -

-The Hurd removes these restrictions from the user. It provides an -user extensible system framework without giving up POSIX compatibility -and the unix security model. Throughout this talk, we will see that -this brings further advantages beside freedom. - -

Overview

-
- -

-The Hurd is a POSIX compatible multi-server -system operating on top of the GNU Mach microkernel. - -

-Topics: -

    -
  • GNU Mach
    • -
  • The Hurd
    • -
  • Development
    • -
  • Debian GNU/Hurd
    • -
-
- -

-The Hurd is a POSIX compatible multi-server system operating on top of -the GNU Mach Microkernel. - -

-I will have to explain what GNU Mach is, so we start with that. Then -I will talk about the Hurd's architecture. After that, I will give a -short overview on the Hurd libraries. Finally, I will tell you how -the Debian project is related to the Hurd. - -

Historicals

- -
-
    -
  • 1983: Richard Stallman founds the GNU project.
    • -
  • 1988: Decision is made to use Mach 3.0 as the kernel.
    • -
  • 1991: Mach 3.0 is released under compatible license.
    • -
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
    • -
  • 1994: The Hurd boots the first time.
    • -
  • 1997: Version 0.2 of the Hurd is released.

    • -
  • 1998: Debian hurd-i386 archive is created.
    • -
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
    • -
-
- -

-When Richard Stallman founded the GNU project in 1983, he wanted to -write an operating system consisting only of free software. Very -soon, a lot of the essential tools were implemented, and released -under the GPL. However, one critical piece was missing: The kernel. -

-After considering several alternatives, it was decided not to write a -new kernel from scratch, but to start with the Mach microkernel. This -was in 1988, and it was not before 1991 that Mach was released under a -license allowing the GNU project to distribute it as a part of the -system. -

-In 1998, I started the Debian GNU/Hurd project, and in 2001 the number -of available GNU/Hurd packages fills three CD images. - -

Kernel Architectures

-
-

-Microkernel: -

    -
  • Enforces resource management (paging, scheduling)
    • -
  • Manages tasks
    • -
  • Implements message passing for IPC
    • -
  • Provides basic hardware support
    • -
-

-Monolithic kernel: -

    -
  • No message passing necessary
    • -
  • Rich set of features (filesystems, authentication, network - sockets, POSIX interface, ...)
    • -
-
-

-Microkernels were very popular in the scientific world around that -time. They don't implement a full operating system, but only the -infrastructure needed to enable other tasks to implement most -features. In contrast, monolithical kernels like Linux contain -program code of device drivers, network protocols, process management, -authentication, file systems, POSIX compatible interfaces and much -more. -

-So what are the basic facilities a microkernel provides? In general, -this is resource management and message passing. Resource management, -because the kernel task needs to run in a special privileged mode of -the processor, to be able to manipulate the memory management unit and -perform context switches (also to manage interrupts). Message -passing, because without a basic communication facility the other -tasks could not interact to provide the system services. Some -rudimentary hardware device support is often necessary to bootstrap -the system. So the basic jobs of a microkernel are enforcing the -paging policy (the actual paging can be done by an external pager -task), scheduling, message passing and probably basic hardware device -support. -

-Mach was the obvious choice back then, as it provides a rich set of -interfaces to get the job done. Beside a rather brain-dead device -interface, it provides tasks and threads, a messaging system allowing -synchronous and asynchronous operation and a complex interface for -external pagers. It's certainly not one of the sexiest microkernels -that exist today, but more like a big old mama. The GNU project -maintains its own version of Mach, called GNU Mach, which is based on -Mach 4.0. In addition to the features contained in Mach 4.0, the GNU -version contains many of the Linux 2.0 block device and network card -drivers. -

-A complete treatment of the differences between a microkernel and -monolithical kernel design can not be provided here. But a couple of -advantages of a microkernel design are fairly obvious. - -

Micro vs Monolithic

-
-

-Microkernel -

    -
  • Clear cut responsibilities -
  • Flexibility in operating system design, easier debugging
    • -
  • More stability (less code to break)
    • -
  • New features are not added to the kernel
    • -
-

-Monolithic kernel -

    -
  • Intolerance or creeping featuritis
    • -
  • Danger of spaghetti code
    • -
  • Small changes can have far reaching side effects
    • -
-
-

-Because the system is split up into several components, clean -interfaces have to be developed, and the responsibilities of each part -of the system must be clear. -

-Once a microkernel is written, it can be used as the base for several -different operating systems. Those can even run in parallel which -makes debugging easier. When porting, most of the hardware dependant -code is in the kernel. -

-Much of the code that doesn't need to run in the special kernel mode -of the processor is not part of the kernel, so stability increases -because there is simply less code to break. -

-New features are not added to the kernel, so there is no need to hold -the barrier high for new operating system features. -

-Compare this to a monolithical kernel, where you either suffer from -creeping featuritis or you are intolerant of new features (we see both -in the Linux kernel). -

-Because in a monolithical kernel, all parts of the kernel can access -all data structures in other parts, it is more likely that short cuts -are used to avoid the overhead of a clean interface. This leads to a -simple speed up of the kernel, but also makes it less comprehensible -and more error prone. A small change in one part of the kernel can -break remote other parts. - -

Single Server vs Multi Server

-
-

-Single Server -

    -
  • A single task implements the functionality of the operating system.
    • -
-

-Multi Server -

    -
  • Many tasks cooperate to provide the system's functionality.
    • -
  • One server provides only a small but well-defined part of the - whole system.
    • -
  • The responsibilities are distributed logically among the servers.
    • -
-

-A single-server system is comparable to a monolithic kernel system. It -has similar -advantages and disadvantages. -

-

-There exist a couple of operating systems based on Mach, but they all -have the same disadvantages as a monolithical kernel, because those -operating systems are implemented in one single process running on top -of the kernel. This process provides all the services a monolithical -kernel would provide. This doesn't make a whole lot of sense (the -only advantage is that you can probably run several of such isolated -single servers on the same machine). Those systems are also called -single-server systems. The Hurd is the only usable multi-server -system on top of Mach. In the Hurd, there are many server programs, -each one responsible for a unique service provided by the operating -system. These servers run as Mach tasks, and communicate using the -Mach message passing facilities. One of them does only provide a -small part of the functionality of the system, but together they build -up a complete and functional POSIX compatible operating system. - -

Multi Server is superior, ...

-
-

-Any multi-server has advantages over single-server: -

    -
  • Clear cut responsibilities
    • -
  • More stability: If one server dies, all others remain
    • -
  • Easier development cycle: Testing without reboot (or replacing - running servers), debugging with gdb
    • -
  • Easier to make changes and add new features -
-
-

-Using several servers has many advantages, if done right. If a file -system server for a mounted partition crashes, it doesn't take down -the whole system. Instead the partition is "unmounted", and -you can try to start the server again, probably debugging it this time -with gdb. The system is less prone to errors in individual -components, and over-all stability increases. The functionality of -the system can be extended by writing and starting new servers -dynamically. (Developing these new servers is easier for the reasons -just mentioned.) -

-But even in a multi-server system the barrier between the system and -the users remains, and special privileges are needed to cross it. We -have not achieved user freedom yet. - -

The Hurd even more so.

-
-

-The Hurd goes beyond all this, and allows users to write and run their -servers, too! -

    -
  • Users can replace system servers dynamically with their own - implementations.
    • -
  • Users can decide what parts of the remainder of the system they - want to use.
    • -
  • Users can extend the functionality of the system.
    • -
  • No mutual trust necessary to make use of other users - services.
    • -
  • Security of the system is not harmed by trusting users - services.
    • -
-
-

-To quote Thomas Bushnell, BSG, from his paper -``A new strategy towards OS -design'' (1996): -

-The GNU Hurd, by contrast, is designed to make the area of system code -as limited as possible. Programs are required to communicate only -with a few essential parts of the kernel; the rest of the system is -replaceable dynamically. Users can use whatever parts of the -remainder of the system they want, and can easily add components -themselves for other users to take advantage of. No mutual trust need -exist in advance for users to use each other's services, nor does the -system become vulnerable by trusting the services of arbitrary users. -
- -

-So the Hurd is a set of servers running on top of the Mach -micro-kernel, providing a POSIX compatible and extensible operating -system. What servers are there? What functionality do they provide, -and how do they cooperate? - -

Mach Inter Process Communication

-
-

-Ports are message queues which can be used as one-way communication -channels. -

    -
  • Port rights are receive, send or send-once
    • -
  • Exactly one receiver
    • -
  • Potentially many senders
    • -
-

-MIG provides remote procedure calls on top of Mach IPC. RPCs look like -function calls to the user. -

-

-Inter-process communication in Mach is based on the ports concept. A -port is a message queue, used as a one-way communication channel. In -addition to a port, you need a port right, which can be a send right, -receive right, or send-once right. Depending on the port right, you -are allowed to send messages to the server, receive messages from it, -or send just one single message. -

-For every port, there exists exactly one task holding the receive -right, but there can be no or many senders. The send-once right is -useful for clients expecting a response message. They can give a -send-once right to the reply port along with the message. The kernel -guarantees that at some point, a message will be received on the reply -port (this can be a notification that the server destroyed the -send-once right). -

-You don't need to know much about the format a message takes to be -able to use the Mach IPC. The Mach interface generator mig hides the -details of composing and sending a message, as well as receiving the -reply message. To the user, it just looks like a function call, but -in truth the message could be sent over a network to a server running -on a different computer. The set of remote procedure calls a server -provides is the public interface of this server. - - -

How to get a port?

-
-

-Traditional Mach: -

    -
  • Nameserver provides ports to all registered servers.
    • -
  • The nameserver port itself is provided by Mach.
    • -
  • Like a phone book: One list.
    • -
-

-The Hurd: -

    -
  • The filesystem is used as the server namespace.
    • -
  • Root directory port is inserted into each task.
    • -
  • The C library finds other ports with hurd_file_name_lookup, - performing a pathname resolution.
    • -
  • Like a tree of phone books.
    • -
-
-

-So how does one get a port to a server? You need something like a -phone book for server ports, or otherwise you can only talk to -yourself. In the original Mach system, a special nameserver is -dedicated to that job. A task could get a port to the nameserver from -the Mach kernel and ask it for a port (with send right) to a server -that registered itself with the nameserver at some earlier time. -

-In the Hurd, there is no nameserver. Instead, the filesystem is used -as the server namespace. This works because there is always a root -filesystem in the Hurd (remember that the Hurd is a POSIX compatible -system); this is an assumption the people who developed Mach couldn't -make, so they had to choose a different strategy. You can use the -function hurd_file_name_lookup, which is part of the C library, to get -a port to the server belonging to a filename. Then you can start to -send messages to the server in the usual way. - -

Example of hurd_file_name_lookup

-
-mach_port_t identity;
-mach_port_t pwserver;
-kern_return_t err;
-
-pwserver = hurd_file_name_lookup
-                ("/servers/password");
-
-err = password_check_user (pwserver,
-                           0 /* root */, "supass",
-                           &identity);
-
-

-As a concrete example, the special filename -/servers/password can be used to request a port to the -Hurd password server, which is responsible to check user provided -passwords. -

-(explanation of the example) - -

Pathname resolution example

-
-

-Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. -

    -
  • The C library asks the root filesystem server about - /mnt/readme.txt.
    • -
  • The root filesystem returns a port to the mnt filesystem server - (matching /mnt) and the retry name - /readme.txt.
    • -
  • The C library asks the mnt filesystem server about - /readme.txt.
    • -
  • The mnt filesystem server returns a port to itself and records - that this port refers to the regular file - /readme.txt.
    • -
-
-

-The C library itself does not have a full list of all available -servers. Instead pathname resolution is used to traverse through a -tree of servers. In fact, filesystems themselves are implemented by -servers (let us ignore the chicken and egg problem here). So all the -C library can do is to ask the root filesystem server about the -filename provided by the user (assuming that the user wants to resolve -an absolute path), using the dir_lookup RPC. If the -filename refers to a regular file or directory on the filesystem, the -root filesystem server just returns a port to itself and records that -this port corresponds to the file or directory in question. But if a -prefix of the full path matches the path of a server the root -filesystem knows about, it returns to the C library a port to this -server and the remaining part of the pathname that couldn't be -resolved. The C library than has to retry and query the other server -about the remaining path component. Eventually, the C library will -either know that the remaining path can't be resolved by the last -server in the list, or get a valid port to the server in question. - -

Mapping the POSIX Interface

-
- - - - - - - - - - - - - - - - - - - -
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
-[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
-
-

-It should by now be obvious that the port returned by the server can -be used to query the files status, content and other information from -the server, if good remote procedure calls to do that are defined and -implemented by it. This is exactly what happens. Whenever a file is -opened using the C libraries open() call, the C library -uses the above pathname resolution to get a port to a server providing -the file. Then it wraps a file descriptor around it. So in the Hurd, -for every open file descriptor there is a port to a server providing -this file. Many other C library calls like read() and -write() just call a corresponding RPC using the port -associated with the file descriptor. - -

File System Servers

-
-
    -
  • Provide file and directory services for ports (and more).
    • -
  • These ports are returned by a directory lookup.
    • -
  • Translate filesystem accesses through their root path (hence the - name translator).
    • -
  • The C library maps the POSIX file and directory interface (and - more) to RPCs to the filesystem servers ports, but also does work on - its own.
    • -
  • Any user can install file system servers on inodes they own.
    • -
-
-

-So we don't have a single phone book listing all servers, but rather a -tree of servers keeping track of each other. That's really like -calling your friend and asking for the phone number of the blond girl -at the party yesterday. He might refer you to a friend who hopefully -knows more about it. Then you have to retry. -

-This mechanism has huge advantages over a single nameserver. First, -note that standard unix permissions on directories can be used to -restrict access to a server (this requires that the filesystems -providing those directories behave). You just have to set the -permissions of a parent directory accordingly and provide no other way -to get a server port. -

-But there are much deeper implications. Most of all, a pathname never -directly refers to a file, it refers to a port of a server. That -means that providing a regular file with static data is just one of -the many options the server has to service requests on the file port. -A server can also create the data dynamically. For example, a server -associated with /dev/random can provide new random data -on every io_read() on the port to it. A server -associated with /dev/fortune can provide a new fortune -cookie on every open(). -

-While a regular filesystem server will just serve the data as stored -in a filesystem on disk, there are servers providing purely virtual -information, or a mixture of both. It is up to the server to behave -and provide consistent and useful data on each remote procedure call. -If it does not, the results may not match the expectations of the user -and confuse him. -

-A footnote from the Hurd info manual: -

-(1) You are lost in a maze of twisty little filesystems, all -alike.... -
-

-Because a server installed in the filesystem namespace translates all -filesystem operations that go through its root path, such a server is -also called "active translator". You can install translators using -the settrans command with the -a option. - -

Active vs Passive

-
-

-Active Translators: -

    -
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
    • -
  • Are running filesystem servers.
    • -
  • Are attached to the root node they translate.
    • -
  • Run as a normal process.
    • -
  • Go away with every reboot, or even time out.
    • -
-
-

-Many translator settings remain constant for a long time. It would be -very lame to always repeat the same couple of dozens settrans calls -manually or at boot time. So the Hurd provides a filesystem extension -that allows to store translator settings inside the filesystem and let -the filesystem servers do the work to start those servers on demand. -Such translator settings are called "passive translators". A passive -translator is really just a command line string stored in an inode of -the filesystem. If during a pathname resolution a server encounters -such a passive translator, and no active translator does exist already -(for this node), it will use this string to start up a new translator -for this inode, and then let the C library continue with the path -resolution as described above. Passive translators are installed with -settrans using the -p option (which is already the -default). - -
-

-Passive Translators: -

    -
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
    • -
  • Are stored as command strings into an inode.
    • -
  • Are used to start a new active translator if there isn't - one.
    • -
  • Startup is transparent to the user.
    • -
  • Startup happens the first time the server is needed.
    • -
  • Are permanent across reboots (like file data).
    • -
-
-

-So passive translators also serve as a sort of automounting feature, -because no manual interaction is required. The server start up is -deferred until the service is need, and it is transparent to the user. -

-When starting up a passive translator, it will run as a normal process -with the same user and group id as those of the underlying inode. Any -user is allowed to install passive and active translators on inodes -that he owns. This way the user can install new servers into the -global namespace (for example, in his home or tmp directory) and thus -extend the functionality of the system (recall that servers can -implement other remote procedure calls beside those used for files and -directories). A careful design of the trusted system servers makes -sure that no permissions leak out. -

-In addition, users can provide their own implementations of some of -the system servers instead the system default. For example, they can -use their own exec server to start processes. The user specific exec -server could for example start java programs transparently (without -invoking the interpreter manually). This is done by setting the -environment variable EXECSERVERS. The systems default -exec server will evaluate this environment variable and forward the -RPC to each of the servers listed in turn, until some server accepts -it and takes over. The system default exec server will only do this -if there are no security implications. (XXX There are other ways to -start new programs than by using the system exec server. Those are -still available.) -

-Let's take a closer look at some of the Hurd servers. It was already -mentioned that only few system servers are mandatory for users. To -establish your identity within the Hurd system, you have to -communicate with the trusted systems authentication server -auth. To put the system administrator into control over -the system components, the process server does some global -bookkeeping. -

-But even these servers can be ignored. However, registration with the -authentication server is the only way to establish your identity -towards other system servers. Likewise, only tasks registered as -processes with the process server can make use of its services. - -

Authentication

-
-

-A user identity is just a port to an authserver. The auth server -stores four set of ids for it: -

    -
  • effective user ids
    • -
  • effective group ids
    • -
  • available user ids
    • -
  • available group ids
    • -
-

-Basic properties: -

    -
  • Any of these can be empty.
    • -
  • A 0 among the user ids identifies the superuser.
    • -
  • Effective ids are used to check if the user has the - permission.
    • -
  • Available ids can be turned into effective ids on user - request.
    • -
-
-

-The Hurd auth server is used to establish the identity of a user for a -server. Such an identity (which is just a port to the auth server) -consists of a set of effective user ids, a set of effective group ids, -a set of available user ids and a set of available group ids. Any of -these sets can be empty. - -

Operations on authentication ports

-
-

-The auth server provides the following operations on ports: -

    -
  • Merge the ids of two ports into a new one.
    • -
  • Return a new port containing a subset of the ids in a port.
    • -
  • Create a new port with arbitrary ids (superuser only).
    • -
  • Establish a trusted connection between users and servers.
    • -
-
-

-If you have two identities, you can merge them and request an identity -consisting of the unions of the sets from the auth server. You can -also create a new identity consisting only of subsets of an identity -you already have. What you can't do is extending your sets, unless -you are the superuser which is denoted by having the user id 0. - -

Establishing trusted connections

-
-
    -
  • User provides a rendezvous port to the server (with - io_reauthenticate).
    • -
  • User calls auth_user_authenticate on the - authentication port (his identity), passing the rendezvous port.
    • -
  • Server calls auth_server_authenticate on its - authentication port (to a trusted auth server), passing the - rendezvous port and the server port.
    • -
  • If both authentication servers are the same, it can match the - rendezvous ports and return the server port to the user and the user - ids to the server.
    • -
-
-

-Finally, the auth server can establish the identity of a user for a -server. This is done by exchanging a server port and a user identity -if both match the same rendezvous port. The server port will be -returned to the user, while the server is informed about the id sets -of the user. The server can then serve or reject subsequent RPCs by -the user on the server port, based on the identity it received from -the auth server. -

-Anyone can write a server conforming to the auth protocol, but of -course all system servers use a trusted system auth server to -establish the identity of a user. If the user is not using the system -auth server, matching the rendezvous port will fail and no server port -will be returned to the user. Because this practically requires all -programs to use the same auth server, the system auth server is -minimal in every respect, and additional functionality is moved -elsewhere, so user freedom is not unnecessarily restricted. - -

Password Server

-
-

-The password server /servers/password runs as root and -returns a new authentication port in exchange for a unix password. -

-The ids corresponding to the authentication port match the unix user -and group ids. -

-Support for shadow passwords is implemented here. -

-

-The password server sits at /servers/password and runs as -root. It can hand out ports to the auth server in exchange for a unix -password, matching it against the password or shadow file. Several -utilities make use of this server, so they don't need to be setuid -root. - -

Process Server

-
-

-The superuser must remain control over user tasks, so: -

    -
  • All mach tasks are associated with a PID in the system default - proc server.
    • -
-

-Optionally, user tasks can store: -

    -
  • Their environment variables.
    • -
  • Their argument vector.
    • -
  • A port, which others can request based on the PID (like a - nameserver).
    • -
-

-Also implemented in the proc server: -

    -
  • Sessions and process groups.
    • -
  • Global configuration not in Mach, like hostname, hostid, system - version.
    • -
-
-

-The process server is responsible for some global bookkeeping. As -such it has to be trusted and is not replaceable by the user. -However, a user is not required to use any of its service. In that -case the user will not be able to take advantage of the POSIXish -appearance of the Hurd. -

-The Mach Tasks are not as heavy as POSIX processes. For example, -there is no concept of process groups or sessions in Mach. The proc -server fills in the gap. It provides a PID for all Mach tasks, and -also stores the argument line, environment variables and other -information about a process (if the mach tasks provide them, which is -usually the case if you start a process with the default -fork()/exec()). A process can also register -a message port with the proc server, which can then be requested by -anyone. So the proc server also functions as a nameserver using the -process id as the name. -

-The proc server also stores some other miscellaneous information not -provided by Mach, like the hostname, hostid and system version. -Finally, it provides facilities to group processes and their ports -together, as well as to convert between pids, process server ports and -mach task ports. -
-

-User tasks not registering themselve with proc only have a PID assigned. -

-Users can run their own proc server in addition to the system default, -at least for those parts of the interface that don't require superuser -privileges. -

-

-Although the system default proc server can't be avoided (all Mach -tasks spawned by users will get a pid assigned, so the system -administrator can control them), users can run their own additional -process servers if they want, implementing the features not requiring -superuser privileges. - -

Filesystems

-
-

-Store based filesystems -

    -
  • ext2fs
    • -
  • ufs
    • -
  • isofs (iso9660, RockRidge, GNU extensions)
    • -
  • fatfs (under development)
    • -
-

-Network file systems -

    -
  • nfs
    • -
  • ftpfs
    • -
-

-Miscellaneous -

    -
  • hostmux
    • -
  • usermux
    • -
  • tmpfs (under development)
    • -
-
-

-We already talked about translators and the file system service they -provide. Currently, we have translators for the ext2, ufs and iso9660 -filesystems. We also have an nfs client and an ftp filesystem. -Especially the latter is intriguing, as it provides transparent access -to ftp servers in the filesystem. Programs can start to move away -from implementing a plethora of network protocols, as the files are -directly available in the filesystem through the standard POSIX file -interface. - - -

Developing the Hurd

-
-

-Over a dozen libraries support the development of new servers. -

-For special server types highly specialized -libraries require only the implementation of a -number of callback functions. -

    -
  • Use libdiskfs for store based filesystems.
    • -
  • Use libnetfs for network filesystems, also for - virtual filesystems.
    • -
  • Use libtrivfs for simple filesystems providing only - a single file or directory.
    • -
-
-

-The Hurd server protocols are complex enough to allow for the -implementation of a POSIX compatible system with GNU extensions. -However, a lot of code can be shared by all or at least similar -servers. For example, all storage based filesystems need to be able to -read and write to a store medium splitted in blocks. The Hurd comes -with several libraries which make it easy to implement new servers. -Also, there are already a lot of examples of different server types in -the Hurd. This makes writing a new server easier. -

-libdiskfs is a library that supports writing store based -filesystems like ext2fs or ufs. It is not very useful for filesystems -which are purely virtual, like /proc or files in -/dev. -

-libnetfs is intended for filesystems which provide a rich -directory hierarchy, but don't use a backing store (for example ftpfs, -nfs). -

-libtrivfs is intended for filesystems which just provide -a single inode or directory. Most servers which are not intended to -provide a filesystem but other services (like -/servers/password) use it to provide a dummy file, so -that file operations on the servers node will not return errors. But -it can also be used to provide meaningful data in a single file, like -a device store or a character device. - -

Store Abstraction

-
-

-Another very useful library is libstore, which is used by all store -based filesystems. It provides a store media abstraction. A store -consists of a store class and a name (which itself can sometimes -contain stores). -

-Primitive store classes: -

    -
  • device store like device:hd2, device:hd0s1, device:fd0
    • -
  • file store like file:/tmp/disk_image
    • -
  • task store like task:PID
    • -
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
    • -
-
-
-

-Composed store classes: -

    -
  • copy store like copy:zero:4m
    • -
  • gunzip/bunzip2 store like gunzip:device:fd0
    • -
  • concat store like concat:device:hd0s2:device:hd1s5
    • -
  • ileave store (RAID-0(2))
    • -
  • remap store like remap:10+20,50+:file:/tmp/blocks
    • -
  • ...
    • -
-

-Wanted: A similar abstraction for streams (based on channels), which -can be used by network and character device servers. -

-

-libstore provides a store abstraction, which is used by -all store based filesystems. The store is determined by a type and a -name, but some store types modify another store rather than providing -a new store, and thus stores can be stacked. For example, the device -store type expects a Mach device, but the remap store expects a list -of blocks to pick from another store, like remap:1+:device:hd2, which -would pick all blocks from hd2 but the first one, which skipped. -Because this functionality is provided in a library, all libstore -using filesystems support many different store kinds, and adding a new -store type is enough to make all store based filesystems support it. - -

Debian GNU/Hurd

-
-

-Goal: -

    -
  • Provide a binary distribution of the Hurd that is easy to - install.
    • -
-

-Constraints: -

    -
  • Use the same source packages as Debian GNU/Linux.
    • -
  • Use the same infrastructure: -
      -
    • Policy
      • -
    • Archive
      • -
    • Bug tracking system
      • -
    • Release process
      • -
    • -
-

-Side Goal: -

    -
  • Prepare Debian for the future: -
      -
    • More flexibility in the base system
      • -
    • Identify dependencies on the Linux kernel
      • -
    • -
-
-

-The Debian distribution of the GNU Hurd that I started in 1998 is -supposed to become a complete binary distribution of the Hurd that is -easy to install. - -

Status of the Debian GNU/Hurd binary archive

-

-See -http://buildd.debian.org/stats/graph.png -for the most current version of the statistic. - -

Status of the Debian infrastructure

-
-

-Plus: -

    -
  • Source packages can identify build and host OS using - dpkg-architecture.
    • -
-

-Minus: -

    -
  • The binary architecture field is insufficient.
    • -
  • The BTS has no architecture tag.
    • -
  • The policy/FHS need (small) Hurd specific extensions.
    • -
-
-

-While good compatibiity can be achieved at the source level, -the binary packages can not always express their relationship -to the available architectures sufficiently. -

-For example, the Linux version of makedev is binary-all, where -a binary-all-linux relationship would be more appropriate. -

-More work has to be done here to fix the tools. - -

Status of the Debian Source archive

-
-
    -
  • Most packages just work.
    • -
  • Maintainers are usually responsive and cooperative.
    • -
  • Turtle, the autobuilder, crunches through the whole list right - now.
    • -
-

-Common pitfalls are POSIX incompatibilities: -

    -
  • Upstream: -
      -
    • Unconditional use of PATH_MAX - (MAXPATHLEN), MAXHOSTNAMELEN.
      • -
    • Unguarded use of Linux kernel features.
      • -
    • Use of legacy interfaces (sys_errlist, - termio).
      • -
    • -
  • Debian: -
      -
    • Unguarded activation of extensions available with Linux.
      • -
    • Low quality patches.
      • -
    • Assuming GNU/Linux in package scripts.
      • -
    • -
-
-

-Most packages are POSIX compatible and can be compiled without -changes on the Hurd. The maintainers of the Debian source packages -are usually very kind, responsiver and helpful. -

-The Turtle autobuilder software (http://turtle.sourceforge.net) -builds the Debian packages on the Hurd automatically. - -

Debian GNU/Hurd: Good idea, bad idea?

-
-

-Upstream benefits: -

    -
  • Software packages become more portable.
    • -
-

-Debian benefits: -

    -
  • Debian becomes more portable.
    • -
  • Maintainers learn about portability and other systems.
    • -
  • Debian gets a lot of public recognition.
    • -
-

-GNU/Hurd benefits: -

    -
  • Large software base.
    • -
  • Great infrastructure.
    • -
  • Nice community to partner with.
    • -
-
-

-The sheet lists the advantages of all groups involved. - -

End

-
-

-Join us at -

-
-

-List of contacts. - -

-Some of these links are at other web sites not maintained by the -FSF. The FSF is not responsible for the content of these other web sites. - -

- -
- -[ - - - English -] - -
- -

-Return to GNU's home page. -

- -Please send FSF & GNU inquiries & questions to - -gnu@gnu.org. -There are also other ways to -contact the FSF. -

- -Please send comments on these web pages to - -web-hurd@gnu.org, -send other questions to -gnu@gnu.org. -

-Copyright (C) 2001 Marcus Brinkmann <marcus@gnu.org> -

-Verbatim copying and distribution of this entire article is -permitted in any medium, provided this notice is preserved. -

-Updated: - -$Date$ $Author$ - -

- - diff --git a/hurd.mdwn b/hurd.mdwn index 61e83d21..3c65bb4e 100644 --- a/hurd.mdwn +++ b/hurd.mdwn @@ -53,8 +53,6 @@ in the *unstable* branch of the Debian archive. * [[Critique]] - Analysis * [[Hurd_Hacking_Guide]] * [[Concepts]] -* Other resources - * [Docs at gnu.org](http://www.gnu.org/software/hurd/docs.html) # Using diff --git a/hurd/authentication.mdwn b/hurd/authentication.mdwn index cbb164c8..14144d8e 100644 --- a/hurd/authentication.mdwn +++ b/hurd/authentication.mdwn @@ -10,7 +10,7 @@ is included in the section entitled UIDs on the Hurd are separate from processes. A process has [[capabilities|capability]] designating so-called UID vectors that -are implemented by an [[auth]] server. This +are implemented by an [[translator/auth]] server. This makes them easily [[virtualizable|virtualization]]. When a process wishes to gain access to a resource provided by a third diff --git a/hurd/critique.mdwn b/hurd/critique.mdwn index 9770138e..dacd7bb8 100644 --- a/hurd/critique.mdwn +++ b/hurd/critique.mdwn @@ -8,8 +8,8 @@ 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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*A Critique of -the GNU Hurd Multi-Server Operating +Neal Walfield and Marcus Brinkmann wrote a paper titled [*A Critique of +the GNU Hurd Multi-server Operating System*](http://walfield.org/papers/200707-walfield-critique-of-the-GNU-Hurd.pdf). This was published in ACM SIGOPS Operating Systems Review in July 2007. This is sometimes referred to as *the critique*. diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn index bb37a8be..a8c3a988 100644 --- a/hurd/documentation.mdwn +++ b/hurd/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2008 Free Software Foundation, Inc."]] +[[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 @@ -8,10 +9,53 @@ 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]]."]]"""]] +# Introductory Material + * [[What_Is_the_GNU_Hurd]] * [[Advantages]] * [[FAQ]] - * + * [[*Towards_a_New_Strategy_of_OS_Design*|hurd-paper]], an architectural + overview by Thomas Bushnell, BSG. + + * [[*The_Hurd*|hurd-talk]], a presentation by Marcus Brinkmann. + + * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an + analysis of the GNU Hurd on GNU Mach system, written by Neal Walfield and + Marcus Brinkmann. + +## External + + * [*Examining the Legendary HURD + Kernel*](http://www.informit.com/articles/printerfriendly.aspx?p=1180992), + an article by David Chisnall. + + Also covers a bit of GNU's and the Hurd's history, fundamental techniques + applied, comparisions to other systems. + + +# Development + + * *[[The_GNU_Hurd_Reference_Manual|reference_manual]]*. + + * The *[[Hurd_Hacking_Guide]]*, an introduction to GNU Hurd and Mach + programming by Wolfgang Jährling. + + * [*Manually Bootstrapping a + Translator*](http://walfield.org/pub/people/neal/papers/hurd-misc/manual-bootstrap.txt), + a text by Neal Walfield about how to *manually connect the translator to + the filesystem*. + + * [[*The_Authentication_Server*|auth]], the transcript of a talk about the + details of the authentication mechanisms in the Hurd by Wolfgang Jährling. + + * [*The Mach Paging Interface as Used by the + Hurd*](http://lists.gnu.org/archive/html/l4-hurd/2002-06/msg00001.html), a + text by Neal Walfield. + + * In the + [[Position_paper_*Improving_Usability_via_Access_Decomposition_and_Policy*|ng/position_paper]] + Neal Walfield and Marcus Brinkmann give an overview about how a future, + subsequent system may be architected. diff --git a/hurd/documentation/auth.html b/hurd/documentation/auth.html new file mode 100644 index 00000000..487fc1fe --- /dev/null +++ b/hurd/documentation/auth.html @@ -0,0 +1,168 @@ +[[meta copyright="Copyright © 2002, 2008 Free Software Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Authentication Server, the transcript of a talk about the +details of the authentication mechanisms in the Hurd by Wolfgang Jährling"]] + +

Table of Contents

+ +
+ +

Introduction

+

+In this text, which mostly resembles the talk I gave at Libre Software +Meeting 2002 in Bordeaux, I will describe what the auth server does, +why it is so important and which cool things you can do with it, both +on the programming and the user side. I will also describe related +programs like the password and fakeauth servers. Note that this text +is targeted at programmers who want to understand the auth mechanism +in detail and are already familiar with concepts like Remote Procedure +Calls (RPCs) as well as the way User- and Group-IDs are used in the +POSIX world. + +

+The auth server is a very small server, therefore it gives a useful +example when you want to learn how a server typically looks like. One +reason why it is so small is that the auth interface, which it +implements, consists of only four RPCs. You can find the interface in +hurd/hurd/auth.defs and the server itself in hurd/auth/. + +

How IDs are represented and used

+

+Each process holds (usually) one port to auth (an auth_t in C source, +which actually is a mach_port_t, of course). The purpose of auth is +to manage User-IDs and Group-IDs, which is the reason why users often +will have no choice but to make use of the systems main auth server, +which does not listen on /servers/auth; instead you inherit a port to +auth from your parent process. Each such port is (internally in the +auth server) associated with a set of effective User- and Group-IDs as +well as a set of available User- and Group-IDs. So we have four sets +of IDs in total. The available IDs can be turned into corresponding +effective IDs at any time. + +

+When you send an auth_getids RPC on the port you hold, you will get +information about which IDs are associated with it, so you can figure +out which permissions you have. But how will a server know that you +have these permissions and therefore know which actions (e.g. writing +into file "foo") it is supposed to do on your behalf and which not? +The establishing of a trusted connection to a server works as follows: + +

    +
  1. A user wants a server to know its IDs
    2. +
  2. The user requests a reauthentication from the server
    3. +
  3. In this request the user will include a port
    4. +
  4. Both will hand this port to auth
    5. +
  5. The user uses auth_user_authenticate
    6. +
  6. The server uses auth_server_authenticate
    7. +
  7. The server also passes a new port to auth
    8. +
  8. auth matches these two requests
    9. +
  9. The user gets the new port from auth
    10. +
  10. The server learns about the IDs of the user
    11. +
  11. The user uses the new port for further communication
    12. +
+ +

+We have different RPCs for users and servers because what we pass and +what we get back differs for them: Users get a port, and servers get +the sets of IDs, and have to specify the port which the user will get. + +

+It is interesting to note that auth can match the requests by +comparing two integers, because when you get the same port from two +people, you will have the same mach_port_t (which is nothing but an +integer). + +

+All of this of course only works if they use the same auth server, +which is why I said often you have no choice other than to use the +one main auth server. But this is no serious restriction, as the auth server has +almost no functionality one might want to replace. In fact, there is +one replacement for the default auth implementation, but more on that +later. + +

POSIX and beyond

+

+Before we examine what is possible with this design, let us take a +short look at how the POSIX semantics are implemented on top of this +design. When a program that comes out of POSIX-land asks for its own +effective User- or Group-ID, we will tell it about the first of the +effective IDs. In the same sense, the POSIX real User- or Group-ID is +the first available ID and the POSIX saved User- or Group-ID is the +second available ID, which is why you have the same ID two times in +the available IDs when you log into your GNU/Hurd machine (you can +figure out which IDs you have with the program "ids", that basically +just does an auth_getauth RPC). When you lack one of those IDs (for +example when you have no effective Group-ID), a POSIX program asking +for this particular information will get "-1" as the ID. + +

+But as you can imagine, we can do more than what POSIX specifies. Fox +example, we can modify our permissions. This is always done with the +auth_makeauth RPC. In this RPC, you specify the IDs that should be +associated with the new port. All of these IDs must be associated +with either the port where the RPC is sent to or one of the additional +ports you can specify; an exception is the superuser root, which is +allowed to creat ports that are associated with arbitrary IDs. +Hereby you can convert available into effective IDs. + +

+This opens the door to a bunch of nice features. For example, we have +the addauth program in the Hurd, which makes it possible to add an ID +to either a single process or a group of processes if you hold the ID or know the +appropriate password, and there is a corresponding rmauth program that +removes an ID. So when you are working on your computer with GNU +Emacs and want to edit a system configuration file, you switch to +Emacs' shell-mode, do an "addauth root", enter the password, edit the +file, and when you are done switch back to shell-mode and do "rmauth +root". These programs have some interesting options, and there are +various other programs, for setting the complete list of IDs (setauth) +and so on. + +

Related servers

+

+Finally, I want to explain two servers which are related to auth. The +first is the password server, which listens on /servers/password. If +you pass to it a User- or Group-ID and the correct password for it, it +will return a port to auth to you which is associated with the ID you +passed to it. It can create such a port because it is running as +root. So let us assume you are an FTP server process. You will start +as root, because you want to use port 21 (in this case, "port" does +not refer to a mach_port_t, of course). But then, you can drop all +your permissions so that you run without any ID. This makes it far +less dangerous to communicate with yet unknown users over the +network. But when someone now hands a username and password to you, +you can ask the password server for a new auth port. The password +server will check the data you pass to it, for example by looking into +/etc/shadow, and if it is valid, it will ask the auth server for a new +port. It receives this port from auth and then passes it on to you. +So you have raised your permissions. (And for the very curious: Yes, +we are well aware of the differences between this concept and +capabilities; and we also do have some kinds of capabilities in +various parts of the Hurd.) + +

+My second example is the fakeauth server. It also implements the auth +protocol. It is the part of the fakeroot implementation that gives a +process the impression that it runs as root, even if it doesn't. So +when the process asks fakeauth about its own IDs, fakeauth will tell +the process that it runs as root. But when the process wants to make +use of the authentication protocol described earlier in this text, +fakeauth will forward the request to its own auth server, which will +usually be the systems main auth server, which will then be able to +match the auth_*_authenticate requests. So what fakeauth does is +acting as a proxy auth server that gives someone the impression to run +as root, while not modifying what that one is allowed to do. + +

+At this point, I have said at least most of what can be said about the +auth server and the protocol it implements, so I will finish by saying +that it might be an interesting task (for you) to modify some existing +software to take advantage of the features I described here. diff --git a/hurd/documentation/hurd-paper.html b/hurd/documentation/hurd-paper.html new file mode 100644 index 00000000..15d2daec --- /dev/null +++ b/hurd/documentation/hurd-paper.html @@ -0,0 +1,760 @@ +[[meta copyright="Copyright © 1996, 1997, 1998, 2007, 2008 Free Software +Foundation, Inc."]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="Towards a New Strategy of OS Design, an architectural overview by +Thomas Bushnell, BSG."]] + + +This article explains why FSF is developing a new operating system named the +Hurd, which will be a foundation of the whole GNU system. +The Hurd is built +on top of CMU's Mach 3.0 kernel and uses Mach's virtual memory management and +message-passing facilities. +The GNU C Library will provide the Unix system +call interface, and will call the Hurd for needed services it can't provide +itself. +The design and implementation of the Hurd is being lead by Michael +Bushnell, with assistance from Richard Stallman, Roland McGrath, +Jan Brittenson, and others. + +

Part 1: A More Usable Approach to OS Design

+

+The fundamental purpose of an operating system (OS) is to enable a variety of +programs to share a single computer efficiently and productively. +This +demands memory protection, preemptively scheduled timesharing, coordinated +access to I/O peripherals, and other services. +In addition, an OS can allow +several users to share a computer. +In this case, efficiency demands services +that protect users from harming each other, enable them to share without +prior arrangement, and mediate access to physical devices. +

+On today's computer systems, programmers usually implement these goals +through a large program called the kernel. +Since this program must be +accessible to all user programs, it is the natural place to add functionality +to the system. +Since the only model for process interaction is that of +specific, individual services provided by the kernel, no one creates other +places to add functionality. +As time goes by, more and more is added to the +kernel. +

+A traditional system allows users to add components to a kernel only if they +both understand most of it and have a privileged status within the system. +Testing new components requires a much more painful edit-compile-debug cycle +than testing other programs. +It cannot be done while others are using the +system. +Bugs usually cause fatal system crashes, further disrupting others' +use of the system. +The entire kernel is usually non-pageable. +(There are +systems with pageable kernels, but deciding what can be paged is difficult +and error prone. +Usually the mechanisms are complex, making them difficult +to use even when adding simple extensions.) +

+Because of these restrictions, functionality which properly belongs +behind +the wall of a traditional kernel is usually left out of systems unless it is +absolutely mandatory. +Many good ideas, best done with an open/read/write +interface cannot be implemented because of the problems inherent in the +monolithic nature of a traditional system. +Further, even among those with +the endurance to implement new ideas, only those who are privileged users of +their computers can do so. +The software copyright system darkens the mire by +preventing unlicensed people from even reading the kernel source. +

+Some systems have tried to address these difficulties. +Smalltalk-80 and +the Lisp Machine both represented one method of getting around the problem. +System code is not distinguished from user code; all of the system is +accessible to the user and can be changed as need be. +Both systems were +built around languages that facilitated such easy replacement and extension, +and were moderately successful. +But they both were fairly poor at insulating +users and programs from each other, failing one of the principal goals of OS +design. +

+Most projects that use the Mach 3.0 kernel carry on the hard-to-change +tradition of OS design. +The internal structure is different, but the same +heavy barrier between user and system remains. +The single-servers, while +fairly easy to construct, inherit all the deficiencies of the monolithic +kernels. +

+A multi-server divides the kernel functionality up into logical blocks with +well-defined interfaces. +Properly done, it is easier to make changes and add +functionality. +So most multi-server projects do somewhat better. +Much more +of the system is pageable. +You can debug the system more easily. +You can +test new system components without interfering with other users. +But the +wall between user and system remains; no user can cross it without special +privilege. +

+The GNU Hurd, by contrast, is designed to make the area of +system +code as +limited as possible. +Programs are required to communicate only with a few +essential parts of the kernel; the rest of the system is replaceable +dynamically. +Users can use whatever parts of the remainder of the system +they want, and can easily add components themselves for other users to take +advantage of. +No mutual trust need exist in advance for users to use each +other's services, nor does the system become vulnerable by trusting the +services of arbitrary users. +

+This has been done by identifying those system components which users +must +use in order to communicate with each other. +One of these is responsible for +identifying users' identities and is called the + +authentication server. + +In +order to establish each other's identities, programs must communicate, each +with an authentication server they trust. +Another component establishes +control over system components by the superuser, provides global bookkeeping +operations, and is called the + +process server. + +

+Not all user programs need to communicate with the process server; it is only +necessary for programs which require its services. +Likewise, the +authentication server is only necessary for programs that wish to communicate +their identity to another. +None of the remaining services carry any special +status; not the network implementation, the filesystems, the program +execution mechanism (including setuid), or any others. + +

The Translator Mechanism

+

+The Hurd uses Mach ports primarily as methods for communicating between users +and servers. +(A Mach port is a communication point on a Mach task where +messages are sent and received.) Each port implements a particular set of +protocols, representing operations that can be undertaken on the underlying +object represented by the port. +Some of the protocols specified by the Hurd +are the I/O protocol, used for generic I/O operations; the file protocol, +used for filesystem operations; the socket protocol, used for network +operations; and the process protocol, used for manipulating processes et al. +

+Most servers are accessed by opening files. +Normally, when you open a file, +you create a port associated with that file that is owned by the server +that owns the directory containing the file. +For example, a disk-based +filesystem will normally serve a large number of ports, each of which +represents an open file or directory. +When a file is opened, the server +creates a new port, associates it with the file, and returns the port to the +calling program. +

+However, a file can have a +translator +associated with it. +In this case, +rather than return its own port which refers to the contents of the file, the +server executes a translator program associated with that file. +This +translator is given a port to the actual contents of the file, and is then +asked to return a port to the original user to complete the open operation. +

+This mechanism is used for +mount +by having a translator associated with +each mount point. +When a program opens the mount point, the translator (in +this case, a program which understands the disk format of the mounted +filesystem) is executed and returns a port to the program. +After the +translator is started, it need not be run again unless it dies; the parent +filesystem retains a port to the translator to use in further requests. +

+The owner of a file can associate a translator with it without special +permission. +This means that any program can be specified as a translator. +Obviously the system will not work properly if the translator does not +implement the file protocol correctly. +However, the Hurd is constructed so +that the worst possible consequence is an interruptible hang. +

+One way to use translators is to access hierarchically structured data using +the file protocol. +For example, all the complexity of the user interface to +the +ftp +program is removed. +Users need only know that a particular +directory represents FTP and can use all the standard file manipulation +commands (e.g +ls +or +cp) +to access the remote system, rather than learning +a new set. +Similarly, a simple translator could ease the complexity of +tar +or +gzip. +(Such transparent access would have some added cost, but it would +be convenient.) + +

Generic Services

+

+With translators, the filesystem can act as a rendezvous for interfaces which +are not similar to files. +Consider a service which implements some version +of the X protocol, using Mach messages as an underlying transport. +For each +X display, a file can be created with the appropriate program as its +translator. +X clients would open that file. +At that point, few file +operations would be useful (read and write, for example, would be useless), +but new operations ( +XCreateWindow +or +XDrawText) +might become meaningful. +In this case, the filesystem protocol is used only to manipulate +characteristics of the node used for the rendezvous. +The node need not +support I/O operations, though it should reply to any such messages with a +message_not_understood +return code. +

+This translator technique is used to contact most of the services in the Hurd +that are not structured like hierarchical filesystems. +For example, the +password server, which hands out authorization tags in exchange for +passwords, is contacted this way. +Network protocol servers are also +contacted in this fashion. +Roland McGrath thought up this use of translators. + +

Clever Filesystem Pictures

+

+In the Hurd, translators can also be used to present a filesystem-like view +of another part of the filesystem, with some semantics changed. +For example, +it would be nice to have a filesystem that cannot itself be changed, but +nonetheless records changed versions of its files elsewhere. +(This could be +useful for source code management.) +

+The Hurd will have a translator which creates a directory which is a +conceptual union of other directories, with collision resolution rules of +various sorts. +This can be used to present a single directory to users that +contains all the programs they would want to execute. +There are other useful +variations on this theme. + +

What The User Can Do

+

+No translator gains extra privilege by virtue of being hooked into the +filesystem. +Translators run with the uid of the owner of the file being +translated, and can only be set or changed by that owner. +The I/O and +filesystem protocols are carefully designed to allow their use by mutually +untrusting clients and servers. +Indeed, translators are just ordinary +programs. +The GNU C library has a variety of facilities to make common sorts +of translators easier to write. +

+Some translators may need special privileges, such as the password server or +translators which allow setuid execution. +These translators could be run by +anyone, but only if they are set on a root-owned node would they be able to +provide all their services successfully. +This is analogous to letting any +user call the +reboot +system call, but only honoring it if that user is root. + +

Why This Is So Different

+

+What this design provides is completely novel to the Unix world. +Until now, +OSs have kept huge portions of their functionality in the realm of system +code, thus preventing its modification and extension except in extreme need. +Users cannot replace parts of the system in their programs no matter how much +easier that would make their task, and system managers are loath to install +random tweaks off the net into their kernels. +

+In the Hurd, users can change almost all of the things that are decided for +them in advance by traditional systems. +In combination with the tremendous +control given by the Mach kernel over task address spaces and properties, the +Hurd provides a system in which users will, for the first time, be able to +replace parts of the system they dislike, without disrupting other users. +

+Most Mach-based OSs to date have mostly implemented a wider set of the + +same old + +Unix semantics in a new environment. +In contrast, GNU is extending +those semantics to allow users to improve, bypass, or replace them. + + +

Part 2: A Look at Some of the Hurd's Beasts

+

The Authentication Server

+

+One of the Hurd's more central servers is the authentication server. +Each +port to this server identifies a user and is associated by this server with +an +id block. +Each id block contains sets of user and group ids. +Either +set may be empty. +This server is not the same as the password server +referred to above. +

+The authentication server exports three services. +First, it provides simple +boolean operations on authentication ports: given two authentication ports, +this server will provide a third port representing the union of the two sets +of uids and gids. +Second, this server allows any user with a uid of zero to +create an arbitrary authentication port. +Finally, this server provides RPCs +(Remote Procedure Calls between different programs and possibly different +hosts) which allow mutually untrusting clients and servers to establish their +identities and pass initial information on each other. +This is crucial to +the security of the filesystem and I/O protocols. +

+Any user could write a program which implements the authentication protocol; +this does not violate the system's security. +When a service needs to +authenticate a user, it communicates with its trusted authentication server. +If that user is using a different authentication server, the transaction will +fail and the server can refuse to communicate further. +Because, in effect, +this forces all programs on the system to use the same authentication server, +we have designed its interface to make any safe operation possible, and to +include no extraneous operations. +(This is why there is a separate password +server.) +

The Process Server

+

+The process server acts as an information categorization repository. +There +are four main services supported by this server. +First, the process server +keeps track of generic host-level information not handled by the Mach kernel. +For example, the hostname, the hostid, and the system version are maintained +by the process server. +Second, this server maintains the Posix notions of +sessions and process groups, to help out programs that wish to use Posix +features. +

+Third, the process server maintains a one-to-one mapping between Mach tasks +and Hurd processes. +Every task is assigned a pid. +Processes can register a +message port with this server, which can then be given out to any program +which requests it. +This server makes no attempt to keep these message ports +private, so user programs are expected to implement whatever security they +need themselves. +(The GNU C Library provides convenient functions for all +this.) Processes can tell the process server their current `argv' and `envp' +values; this server will then provide, on request, these vectors of arguments +and environment. +This is useful for writing +ps-like +programs and also +makes it easier to hide or change this information. +None of these features +are mandatory. +Programs are free to disregard all of this and never register +themselves with the process server at all. +They will, however, still have a +pid assigned. +

+Finally, the process server implements +process collections, +which are used +to collect a number of process message ports at the same time. +Also, +facilities are provided for converting between pids, process server ports, +and Mach task ports, while ensuring the security of the ports managed. +

+It is important to stress that the process server is optional. +Because of +restrictions in Mach, programs must run as root in order to identify all the +tasks in the system. +But given that, multiple process servers could +co-exist, each with their own clients, giving their own model of the +universe. +Those process server features which do not require root privileges +to be implemented could be done as per-user servers. +The user's hands are +not tied. +

Transparent FTP

+

+Transparent FTP is an intriguing idea whose time has come. +The popular +ange-ftp +package available for GNU Emacs makes access to FTP files +virtually transparent to all the Emacs file manipulation functions. +Transparent FTP does the same thing, but in a system wide fashion. +This +server is not yet written; the details remain to be fleshed out, and will +doubtless change with experience. +

+In a BSD kernel, a transparent FTP filesystem would be no harder to write +than in the Hurd. +But mention the idea to a BSD kernel hacker, and the +response is that ``such a thing doesn't belong in the kernel''. +In a sense, +this is correct. +It violates all the layering principles of such systems to +place such things in the kernel. +The unfortunate side effect, however, is +that the design methodology (which is based on preventing users from changing +things they don't like) is being used to prevent system designers from making +things better. +(Recent BSD kernels make it possible to write a user program +that provides transparent FTP. +An example is +alex, +but it needs to run +with full root privileges.) +

+In the Hurd, there are no obstacles to doing transparent FTP. +A translator +will be provided for the node +/ftp. +The contents of +/ftp +will probably +not be directly listable, though further subdirectories will be. +There will +be a variety of possible formats. +For example, to access files on uunet, one +could + +cd /ftp/ftp.uu.net:anonymous:mib@gnu. + +Or to access files on a remote +account, one might + +cd /ftp/gnu.org:mib:passwd. + +Parts of this +command could be left out and the transparent FTP program would read them +from a user's +.netrc +file. +In the last case, one might just + +cd /ftp/gnu.org; + +when the rest of the data is already in +.netrc. +

+There is no need to do a +cd +first--use any file command. +To find out about +RFC 1097 (the Telnet Subliminal Message Option), just type + +more /ftp/ftp.uu.net/inet/rfc/rfc1097. + +A copy command to a local disk +could be used if the RFC would be read frequently. +

Filesystems

+

+Ordinary filesystems are also being implemented. +The initial release of the +Hurd will contain a filesystem upwardly compatible with the BSD 4.4 Fast File +System. +In addition to the ordinary semantics, it will provide means to +record translators, offer thirty-two bit user ids and group ids, and supply a +new id per file, called the +author +of the file, which can be set by the +owner arbitrarily. +In addition, because users in the Hurd can have multiple +uids (or even none), there is an additional set of permission bits providing +access control for + +unknown user + +(no uids) as distinct from + +known but arbitrary user + +(some uids: the existing +world +category of file +permissions). +

+The Network File System protocol will be implemented using 4.4 BSD as a +starting point. +A log-structured filesystem will also be implemented using +the same ideas as in Sprite, but probably not the same format. +A GNU network +file protocol may be designed in time, or NFS may be extended to remove its +deficiencies. +There will also be various ``little'' filesystems, such as the +MS-DOS filesystem, to help people move files between GNU and other OSs. + +

Terminals

+

+An I/O server will provide the terminal semantics of Posix. +The GNU C +Library has features for keeping track of the controlling terminal and for +arranging to have proper job control signals sent at the proper times, as +well as features for obeying keyboard and hangup signals. +

+Programs will be able to insert a terminal driver into communications +channels in a variety of ways. +Servers like +rlogind +will be able to insert +the terminal protocol onto their network communication port. +Pseudo-terminals will not be necessary, though they will be provided for +backward compatibility with older programs. +No programs in GNU will depend +on them. +

+Nothing about a terminal driver is forced upon users. +A terminal driver +allows a user to get at the underlying communications channel easily, to +bypass itself on an as-needed basis or altogether, or to substitute a +different terminal driver-like program. +In the last case, provided the +alternate program implements the necessary interfaces, it will be used by the +C Library exactly as if it were the ordinary terminal driver. +

+Because of this flexibility, the original terminal driver will not provide +complex line editing features, restricting itself to the behavior found in +Posix and BSD. +In time, there will be a +readline-based +terminal driver, +which will provide complex line-editing features for those users who want +them. +

+The terminal driver will probably not provide good support for the +high-volume, rapid data transmission required by UUCP or SLIP. +Those +programs do not need any of its features. +Instead they will be using the +underlying Mach device ports for terminals, which support moving large +amounts of data efficiently. + +

Executing Programs

+

+The implementation of the +execve +call is spread across three programs. +The +library marshals the argument and environment vectors. +It then sends a +message to the file server that holds the file to be executed. +The file +server checks execute permissions and makes whatever changes it desires in +the exec call. +For example, if the file is marked setuid and the fileserver +has the ability, it will change the user identification of the new image. +The file server also decides if programs which had access to the old task +should continue to have access to the new task. +If the file server is +augmenting permissions, or executing an unreadable image, then the exec needs +to take place in a new Mach task to maintain security. +

+After deciding the policy associated with the new image, the filesystem calls +the exec server to load the task. +This server, using the BFD (Binary File +Descriptor) library, loads the image. +BFD supports a large number of object +file formats; almost any supported format will be executable. +This server +also handles scripts starting with +#!, +running them through the indicated +program. +

+The standard exec server also looks at the environment of the new image; if +it contains a variable +EXECSERVERS +then it uses the programs specified +there as exec servers instead of the system default. +(This is, of course, +not done for execs that the file server has requested be kept secure.) +

+The new image starts running in the GNU C Library, which sends a message to +the exec server to get the arguments, environment, umask, current directory, +etc. +None of this additional state is special to the file or exec servers; +if programs wish, they can use it in a different manner than the Library. + +

New Processes

+

+The +fork +call is implemented almost entirely in the GNU C Library. +The new +task is created by Mach kernel calls. +The C Library arranges to have its +image inherited properly. +The new task is registered with the process server +(though this is not mandatory). +The C Library provides vectors of functions +to be called at fork time: one vector to be called before the fork, one after +in the parent, and one after in the child. +(These features should not be +used to replace the normal fork-calling sequence; it is intended for +libraries which need to close ports or clean up before a fork occurs.) +The C +library will implement both fork calls specified by the draft Posix.4a (the +proposed standard dealing with the threads extension to the real-time +extension). +

+Nothing forces the user to create new tasks this way. +If a program wants to +use almost the normal fork, but with some special characteristics, then it +can do so. +Hooks will be provided by the C Library, or the function can even +be completely replaced. +None of this is possible in a traditional Unix +system. + +

Asynchronous Messages

+

+As mentioned above, the process server maintains a + +message port + +for each +task registered with it. +These ports are public, and are used to send +asynchronous messages to the task. +Signals, for example, are sent to the +message port. +The signal message also provides a port as an indication that +the sender should be trusted to send the signal. +The GNU C Library lists a +variety of ports in a table, each of which identifies a set of signals that +can be sent by anyone who possesses that port. +For example, if the user +possesses the task's kernel port, it is allowed to send any signal. +If the +user possesses a special + +terminal id + +port, it is allowed to send the +keyboard and hangup signals. +Users can add arbitrary new entries into the C +library's signal permissions table. +

+When a process's process group changes, the process server will send it a +message indicating the new process group. +In this case, the process server +proves its authority by providing the task's kernel port. +

+The C library also has messages to add and delete uids currently used by the +process. +If new uids are sent to the program, the library adds them to its +current set, and then exchanges messages with all the I/O servers it knows +about, proving to them its new authorization. +Similarly, a message can +delete uids. +In the latter case, the caller must provide the process's task +port. +(You can't harm a process by giving it extra permission, but you can +harm it by taking permission away.) The Hurd will provide user programs to +send these messages to processes. +For example, the +su +command will be able +to cause all the programs in your current login session, to gain a new uid, +rather than spawn a subshell. +

+The C library will allow programs to add asynchronous messages they wish to +recognize, as well as prevent recognition of the standard set. +

Making It Look Like Unix

+

+The C Library will implement all of the calls from BSD and Posix as well as +some obvious extensions to them. +This enables users to replace those calls +they dislike or bypass them entirely, whereas in Unix the calls must be used +``as they come'' with no alternatives possible. +

+In some environments binary compatibility will also be supported. +This works +by building a special version of the library which is then loaded somewhere +in the address space of the process. +(For example, on a VAX, it would be +tucked in above the stack.) A feature of Mach, called system call +redirection, is then used to trap Unix system calls and turn them into jumps +into this special version of the library. +(On almost all machines, the cost +of such a redirection is very small; this is a highly optimized path in Mach. +On a 386 it's about two dozen instructions. +This is little worse than a +simple procedure call.) +

+Many features of Unix, such as signal masks and vectors, are handled +completely by the library. +This makes such features significantly cheaper +than in Unix. +It is now reasonable to use +sigblock +extensively to protect +critical sections, rather than seeking out some other, less expensive method. + +

Network Protocols

+

+The Hurd will have a library that will make it very easy to port 4.4 BSD +protocol stacks into the Hurd. +This will enable operation, virtually for +free, of all the protocols supported by BSD. +Currently, this includes the +CCITT protocols, the TCP/IP protocols, the Xerox NS protocols, and the ISO +protocols. +

+For optimal performance some work would be necessary to take advantage of +Hurd features that provide for very high speed I/O. +For most protocols this +will require some thought, but not too much time. +The Hurd will run the +TCP/IP protocols as efficiently as possible. +

+As an interesting example of the flexibility of the Hurd design, consider the +case of IP trailers, used extensively in BSD for performance. +While the Hurd +will be willing to send and receive trailers, it will gain fairly little +advantage in doing so because there is no requirement that data be copied and +avoiding copies for page-aligned data is irrelevant. diff --git a/hurd/documentation/hurd-talk.html b/hurd/documentation/hurd-talk.html new file mode 100644 index 00000000..d608e12a --- /dev/null +++ b/hurd/documentation/hurd-talk.html @@ -0,0 +1,1061 @@ +[[meta copyright="Copyright © 2001 Marcus Brinkmann"]] + +[[meta license="Verbatim copying and distribution of this entire article is +permitted in any medium, provided this notice is preserved."]] + +[[meta title="The Hurd, a presentation by Marcus Brinkmann"]] + + +

Table of Contents

+ +
+

Talk about the Hurd

+

+This talk about the Hurd was written by Marcus Brinkmann for +

    +
  • OSDEM, Brussels, 4. Feb 2001, +
  • Frühjahrsfachgespräche, Cologne, 2. Mar 2001 and +
  • Libre Software Meeting, Bordeaux, 4. Jul 2001. +
+ +

Introduction

+

+When we talk about free software, we usually refer to the free +software licenses. We also need relief from software patents, so our +freedom is not restricted by them. But there is a third type of +freedom we need, and that's user freedom. + +

+Expert users don't take a system as it is. They like to change the +configuration, and they want to run the software that works best for +them. That includes window managers as well as your favourite text +editor. But even on a GNU/Linux system consisting only of free +software, you can not easily use the filesystem format, network +protocol or binary format you want without special privileges. In +traditional unix systems, user freedom is severly restricted by the +system administrator. + +

+The Hurd removes these restrictions from the user. It provides an +user extensible system framework without giving up POSIX compatibility +and the unix security model. Throughout this talk, we will see that +this brings further advantages beside freedom. + +

Overview

+
+ +

+The Hurd is a POSIX compatible multi-server +system operating on top of the GNU Mach microkernel. + +

+Topics: +

    +
  • GNU Mach
    • +
  • The Hurd
    • +
  • Development
    • +
  • Debian GNU/Hurd
    • +
+
+ +

+The Hurd is a POSIX compatible multi-server system operating on top of +the GNU Mach Microkernel. + +

+I will have to explain what GNU Mach is, so we start with that. Then +I will talk about the Hurd's architecture. After that, I will give a +short overview on the Hurd libraries. Finally, I will tell you how +the Debian project is related to the Hurd. + +

Historicals

+ +
+
    +
  • 1983: Richard Stallman founds the GNU project.
    • +
  • 1988: Decision is made to use Mach 3.0 as the kernel.
    • +
  • 1991: Mach 3.0 is released under compatible license.
    • +
  • 1991: Thomas Bushnell, BSG, founds the Hurd project.
    • +
  • 1994: The Hurd boots the first time.
    • +
  • 1997: Version 0.2 of the Hurd is released.

    • +
  • 1998: Debian hurd-i386 archive is created.
    • +
  • 2001: Debian GNU/Hurd snapshot fills three CD images.
    • +
+
+ +

+When Richard Stallman founded the GNU project in 1983, he wanted to +write an operating system consisting only of free software. Very +soon, a lot of the essential tools were implemented, and released +under the GPL. However, one critical piece was missing: The kernel. +

+After considering several alternatives, it was decided not to write a +new kernel from scratch, but to start with the Mach microkernel. This +was in 1988, and it was not before 1991 that Mach was released under a +license allowing the GNU project to distribute it as a part of the +system. +

+In 1998, I started the Debian GNU/Hurd project, and in 2001 the number +of available GNU/Hurd packages fills three CD images. + +

Kernel Architectures

+
+

+Microkernel: +

    +
  • Enforces resource management (paging, scheduling)
    • +
  • Manages tasks
    • +
  • Implements message passing for IPC
    • +
  • Provides basic hardware support
    • +
+

+Monolithic kernel: +

    +
  • No message passing necessary
    • +
  • Rich set of features (filesystems, authentication, network + sockets, POSIX interface, ...)
    • +
+
+

+Microkernels were very popular in the scientific world around that +time. They don't implement a full operating system, but only the +infrastructure needed to enable other tasks to implement most +features. In contrast, monolithical kernels like Linux contain +program code of device drivers, network protocols, process management, +authentication, file systems, POSIX compatible interfaces and much +more. +

+So what are the basic facilities a microkernel provides? In general, +this is resource management and message passing. Resource management, +because the kernel task needs to run in a special privileged mode of +the processor, to be able to manipulate the memory management unit and +perform context switches (also to manage interrupts). Message +passing, because without a basic communication facility the other +tasks could not interact to provide the system services. Some +rudimentary hardware device support is often necessary to bootstrap +the system. So the basic jobs of a microkernel are enforcing the +paging policy (the actual paging can be done by an external pager +task), scheduling, message passing and probably basic hardware device +support. +

+Mach was the obvious choice back then, as it provides a rich set of +interfaces to get the job done. Beside a rather brain-dead device +interface, it provides tasks and threads, a messaging system allowing +synchronous and asynchronous operation and a complex interface for +external pagers. It's certainly not one of the sexiest microkernels +that exist today, but more like a big old mama. The GNU project +maintains its own version of Mach, called GNU Mach, which is based on +Mach 4.0. In addition to the features contained in Mach 4.0, the GNU +version contains many of the Linux 2.0 block device and network card +drivers. +

+A complete treatment of the differences between a microkernel and +monolithical kernel design can not be provided here. But a couple of +advantages of a microkernel design are fairly obvious. + +

Micro vs Monolithic

+
+

+Microkernel +

    +
  • Clear cut responsibilities +
  • Flexibility in operating system design, easier debugging
    • +
  • More stability (less code to break)
    • +
  • New features are not added to the kernel
    • +
+

+Monolithic kernel +

    +
  • Intolerance or creeping featuritis
    • +
  • Danger of spaghetti code
    • +
  • Small changes can have far reaching side effects
    • +
+
+

+Because the system is split up into several components, clean +interfaces have to be developed, and the responsibilities of each part +of the system must be clear. +

+Once a microkernel is written, it can be used as the base for several +different operating systems. Those can even run in parallel which +makes debugging easier. When porting, most of the hardware dependant +code is in the kernel. +

+Much of the code that doesn't need to run in the special kernel mode +of the processor is not part of the kernel, so stability increases +because there is simply less code to break. +

+New features are not added to the kernel, so there is no need to hold +the barrier high for new operating system features. +

+Compare this to a monolithical kernel, where you either suffer from +creeping featuritis or you are intolerant of new features (we see both +in the Linux kernel). +

+Because in a monolithical kernel, all parts of the kernel can access +all data structures in other parts, it is more likely that short cuts +are used to avoid the overhead of a clean interface. This leads to a +simple speed up of the kernel, but also makes it less comprehensible +and more error prone. A small change in one part of the kernel can +break remote other parts. + +

Single Server vs Multi Server

+
+

+Single Server +

    +
  • A single task implements the functionality of the operating system.
    • +
+

+Multi Server +

    +
  • Many tasks cooperate to provide the system's functionality.
    • +
  • One server provides only a small but well-defined part of the + whole system.
    • +
  • The responsibilities are distributed logically among the servers.
    • +
+

+A single-server system is comparable to a monolithic kernel system. It +has similar +advantages and disadvantages. +

+

+There exist a couple of operating systems based on Mach, but they all +have the same disadvantages as a monolithical kernel, because those +operating systems are implemented in one single process running on top +of the kernel. This process provides all the services a monolithical +kernel would provide. This doesn't make a whole lot of sense (the +only advantage is that you can probably run several of such isolated +single servers on the same machine). Those systems are also called +single-server systems. The Hurd is the only usable multi-server +system on top of Mach. In the Hurd, there are many server programs, +each one responsible for a unique service provided by the operating +system. These servers run as Mach tasks, and communicate using the +Mach message passing facilities. One of them does only provide a +small part of the functionality of the system, but together they build +up a complete and functional POSIX compatible operating system. + +

Multi Server is superior, ...

+
+

+Any multi-server has advantages over single-server: +

    +
  • Clear cut responsibilities
    • +
  • More stability: If one server dies, all others remain
    • +
  • Easier development cycle: Testing without reboot (or replacing + running servers), debugging with gdb
    • +
  • Easier to make changes and add new features +
+
+

+Using several servers has many advantages, if done right. If a file +system server for a mounted partition crashes, it doesn't take down +the whole system. Instead the partition is "unmounted", and +you can try to start the server again, probably debugging it this time +with gdb. The system is less prone to errors in individual +components, and over-all stability increases. The functionality of +the system can be extended by writing and starting new servers +dynamically. (Developing these new servers is easier for the reasons +just mentioned.) +

+But even in a multi-server system the barrier between the system and +the users remains, and special privileges are needed to cross it. We +have not achieved user freedom yet. + +

The Hurd even more so.

+
+

+The Hurd goes beyond all this, and allows users to write and run their +servers, too! +

    +
  • Users can replace system servers dynamically with their own + implementations.
    • +
  • Users can decide what parts of the remainder of the system they + want to use.
    • +
  • Users can extend the functionality of the system.
    • +
  • No mutual trust necessary to make use of other users + services.
    • +
  • Security of the system is not harmed by trusting users + services.
    • +
+
+

+To quote Thomas Bushnell, BSG, from his paper +[[``Towards_a_New_Strategy_of_OS_design''_(1996)|hurd-paper]]: +

+The GNU Hurd, by contrast, is designed to make the area of system code +as limited as possible. Programs are required to communicate only +with a few essential parts of the kernel; the rest of the system is +replaceable dynamically. Users can use whatever parts of the +remainder of the system they want, and can easily add components +themselves for other users to take advantage of. No mutual trust need +exist in advance for users to use each other's services, nor does the +system become vulnerable by trusting the services of arbitrary users. +
+ +

+So the Hurd is a set of servers running on top of the Mach +micro-kernel, providing a POSIX compatible and extensible operating +system. What servers are there? What functionality do they provide, +and how do they cooperate? + +

Mach Inter Process Communication

+
+

+Ports are message queues which can be used as one-way communication +channels. +

    +
  • Port rights are receive, send or send-once
    • +
  • Exactly one receiver
    • +
  • Potentially many senders
    • +
+

+MIG provides remote procedure calls on top of Mach IPC. RPCs look like +function calls to the user. +

+

+Inter-process communication in Mach is based on the ports concept. A +port is a message queue, used as a one-way communication channel. In +addition to a port, you need a port right, which can be a send right, +receive right, or send-once right. Depending on the port right, you +are allowed to send messages to the server, receive messages from it, +or send just one single message. +

+For every port, there exists exactly one task holding the receive +right, but there can be no or many senders. The send-once right is +useful for clients expecting a response message. They can give a +send-once right to the reply port along with the message. The kernel +guarantees that at some point, a message will be received on the reply +port (this can be a notification that the server destroyed the +send-once right). +

+You don't need to know much about the format a message takes to be +able to use the Mach IPC. The Mach interface generator mig hides the +details of composing and sending a message, as well as receiving the +reply message. To the user, it just looks like a function call, but +in truth the message could be sent over a network to a server running +on a different computer. The set of remote procedure calls a server +provides is the public interface of this server. + + +

How to get a port?

+
+

+Traditional Mach: +

    +
  • Nameserver provides ports to all registered servers.
    • +
  • The nameserver port itself is provided by Mach.
    • +
  • Like a phone book: One list.
    • +
+

+The Hurd: +

    +
  • The filesystem is used as the server namespace.
    • +
  • Root directory port is inserted into each task.
    • +
  • The C library finds other ports with hurd_file_name_lookup, + performing a pathname resolution.
    • +
  • Like a tree of phone books.
    • +
+
+

+So how does one get a port to a server? You need something like a +phone book for server ports, or otherwise you can only talk to +yourself. In the original Mach system, a special nameserver is +dedicated to that job. A task could get a port to the nameserver from +the Mach kernel and ask it for a port (with send right) to a server +that registered itself with the nameserver at some earlier time. +

+In the Hurd, there is no nameserver. Instead, the filesystem is used +as the server namespace. This works because there is always a root +filesystem in the Hurd (remember that the Hurd is a POSIX compatible +system); this is an assumption the people who developed Mach couldn't +make, so they had to choose a different strategy. You can use the +function hurd_file_name_lookup, which is part of the C library, to get +a port to the server belonging to a filename. Then you can start to +send messages to the server in the usual way. + +

Example of hurd_file_name_lookup

+
+mach_port_t identity;
+mach_port_t pwserver;
+kern_return_t err;
+
+pwserver = hurd_file_name_lookup
+                ("/servers/password");
+
+err = password_check_user (pwserver,
+                           0 /* root */, "supass",
+                           &identity);
+
+

+As a concrete example, the special filename +/servers/password can be used to request a port to the +Hurd password server, which is responsible to check user provided +passwords. +

+(explanation of the example) + +

Pathname resolution example

+
+

+Task: Lookup /mnt/readme.txt where /mnt has a mounted filesystem. +

    +
  • The C library asks the root filesystem server about + /mnt/readme.txt.
    • +
  • The root filesystem returns a port to the mnt filesystem server + (matching /mnt) and the retry name + /readme.txt.
    • +
  • The C library asks the mnt filesystem server about + /readme.txt.
    • +
  • The mnt filesystem server returns a port to itself and records + that this port refers to the regular file + /readme.txt.
    • +
+
+

+The C library itself does not have a full list of all available +servers. Instead pathname resolution is used to traverse through a +tree of servers. In fact, filesystems themselves are implemented by +servers (let us ignore the chicken and egg problem here). So all the +C library can do is to ask the root filesystem server about the +filename provided by the user (assuming that the user wants to resolve +an absolute path), using the dir_lookup RPC. If the +filename refers to a regular file or directory on the filesystem, the +root filesystem server just returns a port to itself and records that +this port corresponds to the file or directory in question. But if a +prefix of the full path matches the path of a server the root +filesystem knows about, it returns to the C library a port to this +server and the remaining part of the pathname that couldn't be +resolved. The C library than has to retry and query the other server +about the remaining path component. Eventually, the C library will +either know that the remaining path can't be resolved by the last +server in the list, or get a valid port to the server in question. + +

Mapping the POSIX Interface

+
+ + + + + + + + + + + + + + + + + + + +
FiledescriptorPort to server providing the file
fd = open(name,...)dir_lookup(..,name,..,&port)
+[pathname resolution]
read(fd, ...)io_read(port, ...)
write(fd, ...)io_write(port, ...)
fstat(fd, ...)io_stat(port, ...)
...
+
+

+It should by now be obvious that the port returned by the server can +be used to query the files status, content and other information from +the server, if good remote procedure calls to do that are defined and +implemented by it. This is exactly what happens. Whenever a file is +opened using the C libraries open() call, the C library +uses the above pathname resolution to get a port to a server providing +the file. Then it wraps a file descriptor around it. So in the Hurd, +for every open file descriptor there is a port to a server providing +this file. Many other C library calls like read() and +write() just call a corresponding RPC using the port +associated with the file descriptor. + +

File System Servers

+
+
    +
  • Provide file and directory services for ports (and more).
    • +
  • These ports are returned by a directory lookup.
    • +
  • Translate filesystem accesses through their root path (hence the + name translator).
    • +
  • The C library maps the POSIX file and directory interface (and + more) to RPCs to the filesystem servers ports, but also does work on + its own.
    • +
  • Any user can install file system servers on inodes they own.
    • +
+
+

+So we don't have a single phone book listing all servers, but rather a +tree of servers keeping track of each other. That's really like +calling your friend and asking for the phone number of the blond girl +at the party yesterday. He might refer you to a friend who hopefully +knows more about it. Then you have to retry. +

+This mechanism has huge advantages over a single nameserver. First, +note that standard unix permissions on directories can be used to +restrict access to a server (this requires that the filesystems +providing those directories behave). You just have to set the +permissions of a parent directory accordingly and provide no other way +to get a server port. +

+But there are much deeper implications. Most of all, a pathname never +directly refers to a file, it refers to a port of a server. That +means that providing a regular file with static data is just one of +the many options the server has to service requests on the file port. +A server can also create the data dynamically. For example, a server +associated with /dev/random can provide new random data +on every io_read() on the port to it. A server +associated with /dev/fortune can provide a new fortune +cookie on every open(). +

+While a regular filesystem server will just serve the data as stored +in a filesystem on disk, there are servers providing purely virtual +information, or a mixture of both. It is up to the server to behave +and provide consistent and useful data on each remote procedure call. +If it does not, the results may not match the expectations of the user +and confuse him. +

+A footnote from the Hurd info manual: +

+(1) You are lost in a maze of twisty little filesystems, all +alike.... +
+

+Because a server installed in the filesystem namespace translates all +filesystem operations that go through its root path, such a server is +also called "active translator". You can install translators using +the settrans command with the -a option. + +

Active vs Passive

+
+

+Active Translators: +

    +
  • "settrans -a /cdrom /hurd/isofs /dev/hd2"
    • +
  • Are running filesystem servers.
    • +
  • Are attached to the root node they translate.
    • +
  • Run as a normal process.
    • +
  • Go away with every reboot, or even time out.
    • +
+
+

+Many translator settings remain constant for a long time. It would be +very lame to always repeat the same couple of dozens settrans calls +manually or at boot time. So the Hurd provides a filesystem extension +that allows to store translator settings inside the filesystem and let +the filesystem servers do the work to start those servers on demand. +Such translator settings are called "passive translators". A passive +translator is really just a command line string stored in an inode of +the filesystem. If during a pathname resolution a server encounters +such a passive translator, and no active translator does exist already +(for this node), it will use this string to start up a new translator +for this inode, and then let the C library continue with the path +resolution as described above. Passive translators are installed with +settrans using the -p option (which is already the +default). + +
+

+Passive Translators: +

    +
  • "settrans /mnt /hurd/ext2fs /dev/hd1s1"
    • +
  • Are stored as command strings into an inode.
    • +
  • Are used to start a new active translator if there isn't + one.
    • +
  • Startup is transparent to the user.
    • +
  • Startup happens the first time the server is needed.
    • +
  • Are permanent across reboots (like file data).
    • +
+
+

+So passive translators also serve as a sort of automounting feature, +because no manual interaction is required. The server start up is +deferred until the service is need, and it is transparent to the user. +

+When starting up a passive translator, it will run as a normal process +with the same user and group id as those of the underlying inode. Any +user is allowed to install passive and active translators on inodes +that he owns. This way the user can install new servers into the +global namespace (for example, in his home or tmp directory) and thus +extend the functionality of the system (recall that servers can +implement other remote procedure calls beside those used for files and +directories). A careful design of the trusted system servers makes +sure that no permissions leak out. +

+In addition, users can provide their own implementations of some of +the system servers instead the system default. For example, they can +use their own exec server to start processes. The user specific exec +server could for example start java programs transparently (without +invoking the interpreter manually). This is done by setting the +environment variable EXECSERVERS. The systems default +exec server will evaluate this environment variable and forward the +RPC to each of the servers listed in turn, until some server accepts +it and takes over. The system default exec server will only do this +if there are no security implications. (XXX There are other ways to +start new programs than by using the system exec server. Those are +still available.) +

+Let's take a closer look at some of the Hurd servers. It was already +mentioned that only few system servers are mandatory for users. To +establish your identity within the Hurd system, you have to +communicate with the trusted systems authentication server +auth. To put the system administrator into control over +the system components, the process server does some global +bookkeeping. +

+But even these servers can be ignored. However, registration with the +authentication server is the only way to establish your identity +towards other system servers. Likewise, only tasks registered as +processes with the process server can make use of its services. + +

Authentication

+
+

+A user identity is just a port to an authserver. The auth server +stores four set of ids for it: +

    +
  • effective user ids
    • +
  • effective group ids
    • +
  • available user ids
    • +
  • available group ids
    • +
+

+Basic properties: +

    +
  • Any of these can be empty.
    • +
  • A 0 among the user ids identifies the superuser.
    • +
  • Effective ids are used to check if the user has the + permission.
    • +
  • Available ids can be turned into effective ids on user + request.
    • +
+
+

+The Hurd auth server is used to establish the identity of a user for a +server. Such an identity (which is just a port to the auth server) +consists of a set of effective user ids, a set of effective group ids, +a set of available user ids and a set of available group ids. Any of +these sets can be empty. + +

Operations on authentication ports

+
+

+The auth server provides the following operations on ports: +

    +
  • Merge the ids of two ports into a new one.
    • +
  • Return a new port containing a subset of the ids in a port.
    • +
  • Create a new port with arbitrary ids (superuser only).
    • +
  • Establish a trusted connection between users and servers.
    • +
+
+

+If you have two identities, you can merge them and request an identity +consisting of the unions of the sets from the auth server. You can +also create a new identity consisting only of subsets of an identity +you already have. What you can't do is extending your sets, unless +you are the superuser which is denoted by having the user id 0. + +

Establishing trusted connections

+
+
    +
  • User provides a rendezvous port to the server (with + io_reauthenticate).
    • +
  • User calls auth_user_authenticate on the + authentication port (his identity), passing the rendezvous port.
    • +
  • Server calls auth_server_authenticate on its + authentication port (to a trusted auth server), passing the + rendezvous port and the server port.
    • +
  • If both authentication servers are the same, it can match the + rendezvous ports and return the server port to the user and the user + ids to the server.
    • +
+
+

+Finally, the auth server can establish the identity of a user for a +server. This is done by exchanging a server port and a user identity +if both match the same rendezvous port. The server port will be +returned to the user, while the server is informed about the id sets +of the user. The server can then serve or reject subsequent RPCs by +the user on the server port, based on the identity it received from +the auth server. +

+Anyone can write a server conforming to the auth protocol, but of +course all system servers use a trusted system auth server to +establish the identity of a user. If the user is not using the system +auth server, matching the rendezvous port will fail and no server port +will be returned to the user. Because this practically requires all +programs to use the same auth server, the system auth server is +minimal in every respect, and additional functionality is moved +elsewhere, so user freedom is not unnecessarily restricted. + +

Password Server

+
+

+The password server /servers/password runs as root and +returns a new authentication port in exchange for a unix password. +

+The ids corresponding to the authentication port match the unix user +and group ids. +

+Support for shadow passwords is implemented here. +

+

+The password server sits at /servers/password and runs as +root. It can hand out ports to the auth server in exchange for a unix +password, matching it against the password or shadow file. Several +utilities make use of this server, so they don't need to be setuid +root. + +

Process Server

+
+

+The superuser must remain control over user tasks, so: +

    +
  • All mach tasks are associated with a PID in the system default + proc server.
    • +
+

+Optionally, user tasks can store: +

    +
  • Their environment variables.
    • +
  • Their argument vector.
    • +
  • A port, which others can request based on the PID (like a + nameserver).
    • +
+

+Also implemented in the proc server: +

    +
  • Sessions and process groups.
    • +
  • Global configuration not in Mach, like hostname, hostid, system + version.
    • +
+
+

+The process server is responsible for some global bookkeeping. As +such it has to be trusted and is not replaceable by the user. +However, a user is not required to use any of its service. In that +case the user will not be able to take advantage of the POSIXish +appearance of the Hurd. +

+The Mach Tasks are not as heavy as POSIX processes. For example, +there is no concept of process groups or sessions in Mach. The proc +server fills in the gap. It provides a PID for all Mach tasks, and +also stores the argument line, environment variables and other +information about a process (if the mach tasks provide them, which is +usually the case if you start a process with the default +fork()/exec()). A process can also register +a message port with the proc server, which can then be requested by +anyone. So the proc server also functions as a nameserver using the +process id as the name. +

+The proc server also stores some other miscellaneous information not +provided by Mach, like the hostname, hostid and system version. +Finally, it provides facilities to group processes and their ports +together, as well as to convert between pids, process server ports and +mach task ports. +
+

+User tasks not registering themselve with proc only have a PID assigned. +

+Users can run their own proc server in addition to the system default, +at least for those parts of the interface that don't require superuser +privileges. +

+

+Although the system default proc server can't be avoided (all Mach +tasks spawned by users will get a pid assigned, so the system +administrator can control them), users can run their own additional +process servers if they want, implementing the features not requiring +superuser privileges. + +

Filesystems

+
+

+Store based filesystems +

    +
  • ext2fs
    • +
  • ufs
    • +
  • isofs (iso9660, RockRidge, GNU extensions)
    • +
  • fatfs (under development)
    • +
+

+Network file systems +

    +
  • nfs
    • +
  • ftpfs
    • +
+

+Miscellaneous +

    +
  • hostmux
    • +
  • usermux
    • +
  • tmpfs (under development)
    • +
+
+

+We already talked about translators and the file system service they +provide. Currently, we have translators for the ext2, ufs and iso9660 +filesystems. We also have an nfs client and an ftp filesystem. +Especially the latter is intriguing, as it provides transparent access +to ftp servers in the filesystem. Programs can start to move away +from implementing a plethora of network protocols, as the files are +directly available in the filesystem through the standard POSIX file +interface. + + +

Developing the Hurd

+
+

+Over a dozen libraries support the development of new servers. +

+For special server types highly specialized +libraries require only the implementation of a +number of callback functions. +

    +
  • Use libdiskfs for store based filesystems.
    • +
  • Use libnetfs for network filesystems, also for + virtual filesystems.
    • +
  • Use libtrivfs for simple filesystems providing only + a single file or directory.
    • +
+
+

+The Hurd server protocols are complex enough to allow for the +implementation of a POSIX compatible system with GNU extensions. +However, a lot of code can be shared by all or at least similar +servers. For example, all storage based filesystems need to be able to +read and write to a store medium splitted in blocks. The Hurd comes +with several libraries which make it easy to implement new servers. +Also, there are already a lot of examples of different server types in +the Hurd. This makes writing a new server easier. +

+libdiskfs is a library that supports writing store based +filesystems like ext2fs or ufs. It is not very useful for filesystems +which are purely virtual, like /proc or files in +/dev. +

+libnetfs is intended for filesystems which provide a rich +directory hierarchy, but don't use a backing store (for example ftpfs, +nfs). +

+libtrivfs is intended for filesystems which just provide +a single inode or directory. Most servers which are not intended to +provide a filesystem but other services (like +/servers/password) use it to provide a dummy file, so +that file operations on the servers node will not return errors. But +it can also be used to provide meaningful data in a single file, like +a device store or a character device. + +

Store Abstraction

+
+

+Another very useful library is libstore, which is used by all store +based filesystems. It provides a store media abstraction. A store +consists of a store class and a name (which itself can sometimes +contain stores). +

+Primitive store classes: +

    +
  • device store like device:hd2, device:hd0s1, device:fd0
    • +
  • file store like file:/tmp/disk_image
    • +
  • task store like task:PID
    • +
  • zero store like zero:4m (like /dev/zero, of size 4 MB)
    • +
+
+
+

+Composed store classes: +

    +
  • copy store like copy:zero:4m
    • +
  • gunzip/bunzip2 store like gunzip:device:fd0
    • +
  • concat store like concat:device:hd0s2:device:hd1s5
    • +
  • ileave store (RAID-0(2))
    • +
  • remap store like remap:10+20,50+:file:/tmp/blocks
    • +
  • ...
    • +
+

+Wanted: A similar abstraction for streams (based on channels), which +can be used by network and character device servers. +

+

+libstore provides a store abstraction, which is used by +all store based filesystems. The store is determined by a type and a +name, but some store types modify another store rather than providing +a new store, and thus stores can be stacked. For example, the device +store type expects a Mach device, but the remap store expects a list +of blocks to pick from another store, like remap:1+:device:hd2, which +would pick all blocks from hd2 but the first one, which skipped. +Because this functionality is provided in a library, all libstore +using filesystems support many different store kinds, and adding a new +store type is enough to make all store based filesystems support it. + +

Debian GNU/Hurd

+
+

+Goal: +

    +
  • Provide a binary distribution of the Hurd that is easy to + install.
    • +
+

+Constraints: +

    +
  • Use the same source packages as Debian GNU/Linux.
    • +
  • Use the same infrastructure: +
      +
    • Policy
      • +
    • Archive
      • +
    • Bug tracking system
      • +
    • Release process
      • +
    • +
+

+Side Goal: +

    +
  • Prepare Debian for the future: +
      +
    • More flexibility in the base system
      • +
    • Identify dependencies on the Linux kernel
      • +
    • +
+
+

+The Debian distribution of the GNU Hurd that I started in 1998 is +supposed to become a complete binary distribution of the Hurd that is +easy to install. + +

Status of the Debian GNU/Hurd binary archive

+

+See +http://buildd.debian.org/stats/graph.png +for the most current version of the statistic. + +

Status of the Debian infrastructure

+
+

+Plus: +

    +
  • Source packages can identify build and host OS using + dpkg-architecture.
    • +
+

+Minus: +

    +
  • The binary architecture field is insufficient.
    • +
  • The BTS has no architecture tag.
    • +
  • The policy/FHS need (small) Hurd specific extensions.
    • +
+
+

+While good compatibiity can be achieved at the source level, +the binary packages can not always express their relationship +to the available architectures sufficiently. +

+For example, the Linux version of makedev is binary-all, where +a binary-all-linux relationship would be more appropriate. +

+More work has to be done here to fix the tools. + +

Status of the Debian Source archive

+
+
    +
  • Most packages just work.
    • +
  • Maintainers are usually responsive and cooperative.
    • +
  • Turtle, the autobuilder, crunches through the whole list right + now.
    • +
+

+Common pitfalls are POSIX incompatibilities: +

    +
  • Upstream: +
      +
    • Unconditional use of PATH_MAX + (MAXPATHLEN), MAXHOSTNAMELEN.
      • +
    • Unguarded use of Linux kernel features.
      • +
    • Use of legacy interfaces (sys_errlist, + termio).
      • +
    • +
  • Debian: +
      +
    • Unguarded activation of extensions available with Linux.
      • +
    • Low quality patches.
      • +
    • Assuming GNU/Linux in package scripts.
      • +
    • +
+
+

+Most packages are POSIX compatible and can be compiled without +changes on the Hurd. The maintainers of the Debian source packages +are usually very kind, responsiver and helpful. +

+The Turtle autobuilder software (http://turtle.sourceforge.net) +builds the Debian packages on the Hurd automatically. + +

Debian GNU/Hurd: Good idea, bad idea?

+
+

+Upstream benefits: +

    +
  • Software packages become more portable.
    • +
+

+Debian benefits: +

    +
  • Debian becomes more portable.
    • +
  • Maintainers learn about portability and other systems.
    • +
  • Debian gets a lot of public recognition.
    • +
+

+GNU/Hurd benefits: +

    +
  • Large software base.
    • +
  • Great infrastructure.
    • +
  • Nice community to partner with.
    • +
+
+

+The sheet lists the advantages of all groups involved. + +

End

+
+

+Join us at +

+
+

+List of contacts. diff --git a/hurd/hurd_hacking_guide.mdwn b/hurd/hurd_hacking_guide.mdwn index 0cb96f32..2ef08f8a 100644 --- a/hurd/hurd_hacking_guide.mdwn +++ b/hurd/hurd_hacking_guide.mdwn @@ -8,6 +8,16 @@ 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]]."]]"""]] -Originally written by Wolfgang Jährling, the [Hurd Hacking Guide](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) -contains an overview of some of the Hurd's features. -Also contains a tutorial on writing your own [[translator]]. +Originally written by Wolfgang Jährling, the *Hurd Hacking Guide* contains an +introduction to GNU Hurd and GNU Mach programming, an overview of some of the +Hurd's features. It also contains a tutorial on writing your own +[[translator]]. + + * [HTML version](http://www.gnu.org/software/hurd/hacking-guide/hhg.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/hacking-guide/hhg.ps) + [187kB, 37 pages], + * [ASCII text + version](http://www.gnu.org/software/hurd/hacking-guide/hhg.txt) [59kB], + * [Texinfo source](http://www.gnu.org/software/hurd/hacking-guide/hhg.texi) + [60kB]. diff --git a/hurd/ng/position_paper.mdwn b/hurd/ng/position_paper.mdwn index 3240a41d..e0f4bf60 100644 --- a/hurd/ng/position_paper.mdwn +++ b/hurd/ng/position_paper.mdwn @@ -8,7 +8,8 @@ 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]]."]]"""]] -[[NealWalfield]] and [[MarcusBrinkmann]] wrote a paper titled [*Improving -Usability via Access Decomposition and Policy -Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf). -This is sometimes referred to as *the position paper*. +Neal Walfield and Marcus Brinkmann wrote a paper titled [*Improving Usability +via Access Decomposition and Policy +Refinement*](http://walfield.org/papers/20070104-walfield-access-decomposition-policy-refinement.pdf) +where they give an overview about how a future, subsequent system may be +architected. This is sometimes referred to as *the position paper*. diff --git a/hurd/reference_manual.mdwn b/hurd/reference_manual.mdwn new file mode 100644 index 00000000..5b5bff2d --- /dev/null +++ b/hurd/reference_manual.mdwn @@ -0,0 +1,18 @@ +[[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 Hurd Reference Manual* documents the architecture, the usage and the +programming of the GNU Hurd. At the moment, the manual is quite incomplete. + + * [HTML version](http://www.gnu.org/software/hurd/doc/hurd_toc.html) for + browsing online, + * [PostScript version](http://www.gnu.org/software/hurd/doc/hurd.ps) + [1020KiB, 91 pages]. diff --git a/hurd/running/distrib.mdwn b/hurd/running/distrib.mdwn index fc42e862..b0a6badd 100644 --- a/hurd/running/distrib.mdwn +++ b/hurd/running/distrib.mdwn @@ -94,7 +94,7 @@ about getting applications to work (if possible). * GNU [Coding Standards](http://www.gnu.org/prep/standards.html) * [[TestSuites]] - Posix, Perl, results feedback, etc. -* [docs and papers](http://www.gnu.org/software/hurd/docs.html) +* [[Documentation]] * [[SystemAPILimits]] * [[CodeAnnouncements]] - Recent coding projects related to the Hurd diff --git a/hurd/running/gnu/universal_package_manager.mdwn b/hurd/running/gnu/universal_package_manager.mdwn index 009b26bf..440f1122 100644 --- a/hurd/running/gnu/universal_package_manager.mdwn +++ b/hurd/running/gnu/universal_package_manager.mdwn @@ -127,7 +127,7 @@ OK. I will give you steps. i. Install a GNU System by folowing [[these_instructions|setup]] -ii. Read about GNU Design +ii. Read about GNU Design: [[Towards_a_New_Strategy_of_OS_Design|documentation/hurd-paper]] iii. Read about translators diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn index b9952931..889f02a6 100644 --- a/hurd/translator.mdwn +++ b/hurd/translator.mdwn @@ -43,6 +43,7 @@ See some [[examples]] about how to use translators. # Existing Translators +* [[auth]] * [[pfinet]] * [[pflocal]] * [[hostmux]] diff --git a/hurd/translator/auth.mdwn b/hurd/translator/auth.mdwn new file mode 100644 index 00000000..73e7e025 --- /dev/null +++ b/hurd/translator/auth.mdwn @@ -0,0 +1,13 @@ +[[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_Authentication_Server*|documentation/auth]], the transcript of a talk +about the details of the authentication mechanisms in the Hurd by Wolfgang +Jährling. diff --git a/microkernel/faq/multiserver_microkernel.mdwn b/microkernel/faq/multiserver_microkernel.mdwn index da690425..68ed332c 100644 --- a/microkernel/faq/multiserver_microkernel.mdwn +++ b/microkernel/faq/multiserver_microkernel.mdwn @@ -22,5 +22,5 @@ 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 on OS -design](http://www.gnu.org/software/hurd/hurd-paper.html). +Bushnell, BSG: +[[Towards_a_New_Strategy_of_OS_Design|hurd/documentation/hurd-paper]]. diff --git a/microkernel/mach/documentation.mdwn b/microkernel/mach/documentation.mdwn index fe870386..f6f2eb79 100644 --- a/microkernel/mach/documentation.mdwn +++ b/microkernel/mach/documentation.mdwn @@ -1,4 +1,5 @@ -[[meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[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 @@ -11,12 +12,27 @@ is included in the section entitled - [Meet Mach](http://www.stepwise.com/Articles/Technical/MeetMach.html), a summary of Mach's history and main concepts. + * *[[The_GNU_Mach_Reference_Manual|gnu_mach/reference_manual]]*. + - OSF's [Kernel Interface (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_interface.ps) [Kernel Interface (pdf)](http://shakthimaan.com/downloads/hurd/kernel_interface.pdf) - OSF's [Kernel Principles (ps)](ftp://ftp.cs.cmu.edu/afs/cs/project/mach/public/doc/osf/kernel_principles.ps) [Kernel Principles (pdf)](http://shakthimaan.com/downloads/hurd/kernel_principles.pdf) + * [*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) diff --git a/microkernel/mach/gnu_mach.mdwn b/microkernel/mach/gnu_mach.mdwn index cdb43a6f..19e1ea53 100644 --- a/microkernel/mach/gnu_mach.mdwn +++ b/microkernel/mach/gnu_mach.mdwn @@ -71,6 +71,7 @@ GNU/Hurd. # Development + * [[Reference_Manual]] * [[Building]] * [[Debugging]] * [[Boot_Trace]] diff --git a/microkernel/mach/gnu_mach/reference_manual.mdwn b/microkernel/mach/gnu_mach/reference_manual.mdwn new file mode 100644 index 00000000..225ab176 --- /dev/null +++ b/microkernel/mach/gnu_mach/reference_manual.mdwn @@ -0,0 +1,26 @@ +[[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/mig/documentation.mdwn b/microkernel/mach/mig/documentation.mdwn index 8c977e55..a0bbbe14 100644 --- a/microkernel/mach/mig/documentation.mdwn +++ b/microkernel/mach/mig/documentation.mdwn @@ -66,8 +66,7 @@ pp. 67--77." # Further Relevant Documentation - * The [GNU Mach Reference - Manual](http://www.gnu.org/software/hurd/docs.html#manuals), espacially + * The [[GNU_Mach_Reference_Manual|gnu_mach/reference_manual]], espacially [Chapter 4, Inter Process Communication](http://www.gnu.org/software/hurd/gnumach-doc/Inter-Process-Communication.html), which, for example, explains how the `dealloc` flag -- cgit v1.2.3