From a40099c68f8d0f518a7594cdf296a566ec2e4207 Mon Sep 17 00:00:00 2001 From: "http://larsrasmusson.se/" Date: Sun, 24 Jul 2011 13:05:21 +0200 Subject: spelling typo fix: themselvse -> themselves --- microkernel/mach/port.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index ba2e22c2..7f02628d 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -49,7 +49,7 @@ send-once right. These messages are (probably) queued and when the server task tries to receive messages by having a [[thread]] use its port receive right, it gets the message(s). This is called [[IPC]]. -Port rights themselvse can be [[delegate]]d in a [[message]], too. When the +Port rights themselves can be [[delegate]]d in a [[message]], too. When the receiver dequeues the message, the right is made available to it. The delivery of [[message]]s is reliable and strictly ordered. When a -- cgit v1.2.3 From 6fb6c2a396bb1b851a4ec8a6f5e605a15c218d10 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 25 Jul 2011 11:26:59 +0200 Subject: microkernel/mach/gnumach/hardware_compatibility_list: IRC. SATA. --- .../mach/gnumach/hardware_compatibility_list.mdwn | 15 +++++------ .../hardware_compatibility_list/discussion.mdwn | 29 ++++++++++++++++++++++ 2 files changed, 37 insertions(+), 7 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn index 2152c079..6c984784 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] # CPU Architecture @@ -68,10 +68,11 @@ All common IDE drives should work. Some drive geometries do not work, e.g. drives with hundreds of GiB of storage space, see [[!GNU_Savannah_bug 26425]]. -[[!toggle id="SATA" text="SATA drives may work in compatibility mode."]] - -[[!toggleable id="SATA" text=""" +## SATA + +SATA drives may work in compatibility mode. + This is how booting a [[GNU/Hurd_system|hurd]] will typically fail if GNU Mach couldn't connect to the hard disk, e.g., in a SATA system without IDE compatibility mode: @@ -81,7 +82,7 @@ compatibility mode: There *may* be an option in the system's BIOS setup to configure enabling such a compatibility mode. -"""]] + # Device Drivers diff --git a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn index 69ca3190..2b65956a 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list/discussion.mdwn @@ -1,4 +1,33 @@ +[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + Further information may still be found on and could perhaps be incorporated into that page. --[[tschwinge]] + + +# SATA + +IRC, freenode, +hurd, 2011-07-24 + + youpi: concerning the ide compatibility problem, it seems some + bioses provide several modes + youpi: "legacy ide" and "native ide" + i don't know what native ide really means, but when debugging ide + probing in gnumach, it just looks like there is nothing to detect + and even in this mode, linux uses the ahci driver + apparently native means it still uses the IDE protocol, but + possibly with other IRQs + i.e. you need a PCI driver to handle that + ok -- cgit v1.2.3 From 7466fb272d4941e71024068949d26891881a081c Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 1 Aug 2011 21:53:26 +0200 Subject: gnumach and mig are now in git, not cvs anymore --- microkernel/mach/gnumach/building.mdwn | 7 ++----- microkernel/mach/mig/gnu_mig/building.mdwn | 4 ++-- 2 files changed, 4 insertions(+), 7 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 99e566bb..8b851dde 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -10,12 +10,9 @@ enabled) is around 50 MiB. ### Developers's RCS -See . +See . - $ 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.) + $ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git You then have to create the automatically generatable files: diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index f92f7dbe..33507283 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -5,9 +5,9 @@ If you want to build the Mach Interface Generator yourself instead of just using ## Getting the Source Code You can chose between getting the [sources from the developers' -RCS](http://savannah.gnu.org/cvs/?group=hurd): +RCS](http://savannah.gnu.org/git/?group=hurd): - $ cvs -z3 -d:pserver:anonymous@cvs.savannah.gnu.org:/sources/hurd co mig + $ git clone git://git.savannah.gnu.org:/srv/git/hurd/mig.git ... 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): -- cgit v1.2.3 From 635249e589fba5c0900923e1bbf1d2e60a3c1f29 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 21:47:58 -0400 Subject: Separate Debian and non-Debian build instructions --- microkernel/mach/mig/gnu_mig/building.mdwn | 29 ++++++++++++++--------------- 1 file changed, 14 insertions(+), 15 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 33507283..7d2f2ea3 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -4,8 +4,7 @@ If you want to build the Mach Interface Generator yourself instead of just using ## Getting the Source Code -You can chose between getting the [sources from the developers' -RCS](http://savannah.gnu.org/git/?group=hurd): +You can chose between getting the [sources from the developers' RCS](http://savannah.gnu.org/git/?group=hurd): $ git clone git://git.savannah.gnu.org:/srv/git/hurd/mig.git @@ -17,25 +16,16 @@ 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: -### ... on Debian systems +### Preparing for the Build 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/gnumach/building]] about how to do that, then come back here. - -## Building and Installing - -### ... a _.deb_ file +### Building and Installing ... a _.deb_ file Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): @@ -47,7 +37,16 @@ Start the build process: You can then install / distribute the _.deb_ file which will drop out one directory above the current one. -### [TODO] +## On non-Debian Systems: + +### Preparing for the Build + +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. + +### Building and Installing The Mach Interface Generator has to be built in a separate directory: -- cgit v1.2.3 From 04696f4f6ffc57e2e7787160eab334e34fc5adfe Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 22:05:54 -0400 Subject: Mention 32 bit lib, also autoreconf; formatting --- microkernel/mach/mig/gnu_mig/building.mdwn | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 7d2f2ea3..23dad10c 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -41,22 +41,27 @@ You can then install / distribute the _.deb_ file which will drop out one direct ### Preparing for the Build -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. +Building the Mach Interface Generator requires a C compiler, a standard 32 bit 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/gnumach/building]] about how to do that, then come back here. ### Building and Installing +First, generate the configuration files: + + $ cd mig + $ autoreconf --install + The Mach Interface Generator has to be built in a separate directory: + $ cd .. $ 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: +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" + $ TARGET_CPPFLAGS=-I"$GNU"/include ../mig/configure --prefix="$GNU" --host=i686-unknown-linux-gnu Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: -- cgit v1.2.3 From 576de1b01ecf03d4e175600884e0bf8ff574dcc3 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 22:11:13 -0400 Subject: Make clarification about building with 64 bit --- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 23dad10c..57057d34 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -63,7 +63,7 @@ Find the root directory where you installed GNU Mach's header files and where yo $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../mig/configure --prefix="$GNU" --host=i686-unknown-linux-gnu -Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: +The --host flag above is necessary if you are building on a 64 bit machine. Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: $ make all install -- cgit v1.2.3 From 0724e2c67077fc768e2fef76da45078d4bca4026 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 22:26:03 -0400 Subject: Question: is --host flag always needed? --- microkernel/mach/mig/gnu_mig/discussion.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) create mode 100644 microkernel/mach/mig/gnu_mig/discussion.mdwn (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/discussion.mdwn b/microkernel/mach/mig/gnu_mig/discussion.mdwn new file mode 100644 index 00000000..e5a4dea3 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/discussion.mdwn @@ -0,0 +1,6 @@ +# Builing MIG + +## Non-cross-compiling + +[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] + -- cgit v1.2.3 From 8ab4c8bd7df48a2d4aeb7ab09e6e7400b5d0efe2 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 22:44:26 -0400 Subject: Rearranged instructions for building gnumach --- microkernel/mach/gnumach/building.mdwn | 71 ++++++++++++++++++---------------- 1 file changed, 38 insertions(+), 33 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 8b851dde..d1f4a497 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -14,10 +14,6 @@ See . $ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git -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). @@ -26,9 +22,9 @@ See [here](http://packages.debian.net/source/unstable/gnumach). Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. -## Preparing for the Build +## On Debian Systems: -### ... on Debian systems +### Preparing for the Build Building GNU Mach requires the *build-essential* and *fakeroot* packages, their dependencies and additional packages that are specified by the source gnumach @@ -37,7 +33,27 @@ package: # apt-get install build-essential fakeroot # apt-get build-dep gnumach -### ... on non-Debian systems +### 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|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. + +## On non-Debian Systems: + +### Preparing for the Build 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 @@ -47,27 +63,30 @@ 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 +### Preparation: -### ... Debian `.deb` files +You first have to create the automatically generatable files: -Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. + $ cd gnumach + $ autoreconf --install - $ cd gnumach-20050801 +### Installing only the Header Files -Start the build process with +GNU Mach should be built in a separate directory: - $ dpkg-buildpackage -us -uc -b -rfakeroot + $ mkdir gnumach-build + $ cd gnumach-build -[[GNU_Mach|gnumach]] is now building. To use the new kernel, you must install the -resulting `.deb` package which is located one directory above the build -directory and has a similar name as the build directory, e.g. +Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +it: - # dpkg -i ../gnumach_20050801-4_hurd-i386.deb + $ [...]/gnumach-1-branch/configure --prefix= -You can now reboot your computer and enjoy the new kernel. +Install the header files into e.g. `~/gnu/include/`: + + $ make DESTDIR=~/gnu install-data## Building and Installing -### [TODO] +### Building and Installing GNU Mach should be built in a separate directory: @@ -91,18 +110,4 @@ 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 -- cgit v1.2.3 From ab4696b26f174fda48d79930e8fb703ec2c19b25 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 22:55:28 -0400 Subject: Updated commands for building gnumach --- microkernel/mach/gnumach/building.mdwn | 19 +++++++++++-------- 1 file changed, 11 insertions(+), 8 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index d1f4a497..6d030d3e 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -72,31 +72,34 @@ You first have to create the automatically generatable files: ### Installing only the Header Files -GNU Mach should be built in a separate directory: +GNU Mach and its headers should be built in separate directories: - $ mkdir gnumach-build - $ cd gnumach-build + $ cd .. + $ mkdir gnumach-build-h + $ cd gnumach-build-h -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +Find the path to your GNU Mach sources (`../gnumach`) and configure it: - $ [...]/gnumach-1-branch/configure --prefix= + $ ../gnumach/configure --prefix= --host=i686-unknown-linux-gnu Install the header files into e.g. `~/gnu/include/`: - $ make DESTDIR=~/gnu install-data## Building and Installing + $ make DESTDIR=~/gnu install-data ### Building and Installing GNU Mach should be built in a separate directory: + $ cd .. $ mkdir gnumach-build $ cd gnumach-build -Find the path to your GNU Mach sources (`[...]/gnumach-1-branch`) and configure +Find the path to your GNU Mach sources (`../gnumach`) and configure it: - $ [...]/gnumach-1-branch/configure [TODO] + $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' + $ ../gnumach/configure --host=i686-unknown-linux-gnu Build the kernel image: -- cgit v1.2.3 From 34b5513ffb0752e2bdb8387c18e06d026d073ffc Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 23:04:13 -0400 Subject: Noted diff in instructions for 32 and 64 bit --- microkernel/mach/gnumach/building.mdwn | 8 ++++++-- 1 file changed, 6 insertions(+), 2 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 6d030d3e..07dc3341 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -79,7 +79,7 @@ GNU Mach and its headers should be built in separate directories: $ cd gnumach-build-h Find the path to your GNU Mach sources (`../gnumach`) and configure -it: +it (the --host flag is needed for 64 bit systems): $ ../gnumach/configure --prefix= --host=i686-unknown-linux-gnu @@ -98,8 +98,12 @@ GNU Mach should be built in a separate directory: Find the path to your GNU Mach sources (`../gnumach`) and configure it: + $ ../gnumach/configure + +If you are building on a 64 bit system, do the following instead: + $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' - $ ../gnumach/configure --host=i686-unknown-linux-gnu + $ ../gnumach/configure --host=i686-unknown-linux-gnu Build the kernel image: -- cgit v1.2.3 From 657fc2f401acae2e205e1f0f225f64f9aabc0186 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 23:10:07 -0400 Subject: Cleaned up sources list for building gnumach page --- microkernel/mach/gnumach/building.mdwn | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 07dc3341..ab6fbba0 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -8,15 +8,11 @@ enabled) is around 50 MiB. ## Getting the Source Code -### Developers's RCS - -See . +You can either use the git repository (see ), $ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git -### What Debian is currently using - -See [here](http://packages.debian.net/source/unstable/gnumach). +... or Debian sources, if you're using Debian. (See [here](http://packages.debian.net/source/unstable/gnumach).) $ apt-get source gnumach -- cgit v1.2.3 From ce52e3774a5d413693779b29f8944216c84ad716 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 23:13:11 -0400 Subject: Made deb source name generic --- microkernel/mach/gnumach/building.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index ab6fbba0..5a598d4a 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -33,7 +33,7 @@ package: Change into the directory with the downloaded / unpacked GNU Mach sources, e.g. - $ cd gnumach-20050801 + $ cd gnumach-XXXXXXXX Start the build process with @@ -43,7 +43,7 @@ Start the build process with 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 + # dpkg -i ../gnumach_XXXXXXXX-X_hurd-i386.deb You can now reboot your computer and enjoy the new kernel. -- cgit v1.2.3 From 0fd892609af34d295114d810a55759291b74157f Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Tue, 2 Aug 2011 23:23:39 -0400 Subject: Rearanging, mentioned static lib --- microkernel/mach/gnumach/building.mdwn | 17 +++++++---------- 1 file changed, 7 insertions(+), 10 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 5a598d4a..178a89c0 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -51,23 +51,16 @@ You can now reboot your computer and enjoy the new kernel. ### Preparing for the Build -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/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 +Building GNU Mach requires a C compiler, a static 32 bit standard C library and your favourite flavor of awk (gawk) and GNU make. -### Preparation: +### Installing only the Header Files -You first have to create the automatically generatable files: +First, you have to create the configuartion files: $ cd gnumach $ autoreconf --install -### Installing only the Header Files - GNU Mach and its headers should be built in separate directories: $ cd .. @@ -85,6 +78,10 @@ Install the header files into e.g. `~/gnu/include/`: ### Building and Installing +Building GNU Mach requires you to have the Mach Interface Generator +installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come +back here. + GNU Mach should be built in a separate directory: $ cd .. -- cgit v1.2.3 From 2dbac97ca00a3ea201c4a1a2b2d7a7be0b2e05b0 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 08:50:52 -0400 Subject: Separate 32 and 64 bit instructions --- microkernel/mach/gnumach/building.mdwn | 7 +++++-- microkernel/mach/mig/gnu_mig/building.mdwn | 7 ++++++- 2 files changed, 11 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 178a89c0..08f4b656 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -67,8 +67,11 @@ GNU Mach and its headers should be built in separate directories: $ mkdir gnumach-build-h $ cd gnumach-build-h -Find the path to your GNU Mach sources (`../gnumach`) and configure -it (the --host flag is needed for 64 bit systems): +Find the path to your GNU Mach sources (`../gnumach`) and configure it: + + $ ../gnumach/configure --prefix= + +Instead, use the --host flag on 64 bit systems: $ ../gnumach/configure --prefix= --host=i686-unknown-linux-gnu diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 57057d34..9c313b3b 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -60,10 +60,15 @@ The Mach Interface Generator has to be built in a separate directory: 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 + +The --host flag is necessary if you are building on a 64 bit machine: + $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../mig/configure --prefix="$GNU" --host=i686-unknown-linux-gnu -The --host flag above is necessary if you are building on a 64 bit machine. Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: +Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: $ make all install -- cgit v1.2.3 From 1aaae16a0242a1251b3b5c779513cf92d97a9f85 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:26:13 -0400 Subject: MIG and Gnumach should be build in subdirectories --- microkernel/mach/gnumach/building.mdwn | 16 +++++++--------- microkernel/mach/mig/gnu_mig/building.mdwn | 7 +++---- 2 files changed, 10 insertions(+), 13 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 08f4b656..8fc1c7a1 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -61,19 +61,18 @@ First, you have to create the configuartion files: $ cd gnumach $ autoreconf --install -GNU Mach and its headers should be built in separate directories: +GNU Mach and its headers should be built in a subdirectory: - $ cd .. $ mkdir gnumach-build-h $ cd gnumach-build-h Find the path to your GNU Mach sources (`../gnumach`) and configure it: - $ ../gnumach/configure --prefix= + $ ../configure --prefix= -Instead, use the --host flag on 64 bit systems: +Use the --host flag on 64 bit systems: - $ ../gnumach/configure --prefix= --host=i686-unknown-linux-gnu + $ ../configure --prefix= --host=i686-unknown-linux-gnu Install the header files into e.g. `~/gnu/include/`: @@ -85,21 +84,20 @@ Building GNU Mach requires you to have the Mach Interface Generator installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come back here. -GNU Mach should be built in a separate directory: +GNU Mach should be built in a subdirectory: - $ cd .. $ mkdir gnumach-build $ cd gnumach-build Find the path to your GNU Mach sources (`../gnumach`) and configure it: - $ ../gnumach/configure + $ ../configure If you are building on a 64 bit system, do the following instead: $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' - $ ../gnumach/configure --host=i686-unknown-linux-gnu + $ ../configure --host=i686-unknown-linux-gnu Build the kernel image: diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 9c313b3b..d2d27bc4 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -52,21 +52,20 @@ First, generate the configuration files: $ cd mig $ autoreconf --install -The Mach Interface Generator has to be built in a separate directory: +The Mach Interface Generator should be built in a subdirectory: - $ cd .. $ 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 + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure The --host flag is necessary if you are building on a 64 bit machine: $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../mig/configure --prefix="$GNU" --host=i686-unknown-linux-gnu + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: -- cgit v1.2.3 From 02c70fe4a97f23521a386dca8a85280df201276a Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:44:43 -0400 Subject: build GM headers and code in same dir. explain bug. --- microkernel/mach/gnumach/building.mdwn | 15 ++++++++++----- 1 file changed, 10 insertions(+), 5 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 8fc1c7a1..6fb67087 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -63,8 +63,8 @@ First, you have to create the configuartion files: GNU Mach and its headers should be built in a subdirectory: - $ mkdir gnumach-build-h - $ cd gnumach-build-h + $ mkdir gnumach-build + $ cd gnumach-build Find the path to your GNU Mach sources (`../gnumach`) and configure it: @@ -84,13 +84,18 @@ Building GNU Mach requires you to have the Mach Interface Generator installed. See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come back here. -GNU Mach should be built in a subdirectory: +GNU Mach should be built in a subdirectory create it if you have not already. $ mkdir gnumach-build $ cd gnumach-build -Find the path to your GNU Mach sources (`../gnumach`) and configure -it: +If you previously ran ../configure for installing the header files, you may run +into a bug when you configure and run make below. If that is the case, run "rm +-rf *" in the _build_ directory, and reconfigure. + + $ rm -rf * + +Find the path to your GNU Mach sources (`../gnumach`) and configure it: $ ../configure -- cgit v1.2.3 From df7ecd1e3d25f24628ff52c684e26aaed0c1d1ac Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:46:31 -0400 Subject: clarify that _build_ directory needs to be cleaned. --- microkernel/mach/gnumach/building.mdwn | 1 + 1 file changed, 1 insertion(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 6fb67087..5226a4b0 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -93,6 +93,7 @@ If you previously ran ../configure for installing the header files, you may run into a bug when you configure and run make below. If that is the case, run "rm -rf *" in the _build_ directory, and reconfigure. + $ cd gnumach-build $ rm -rf * Find the path to your GNU Mach sources (`../gnumach`) and configure it: -- cgit v1.2.3 From 0a00caab9e037e46a3ca6d579fe1cfb4f752c6cb Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:48:06 -0400 Subject: fix directory name --- microkernel/mach/gnumach/building.mdwn | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 5226a4b0..015046e6 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -66,7 +66,7 @@ GNU Mach and its headers should be built in a subdirectory: $ mkdir gnumach-build $ cd gnumach-build -Find the path to your GNU Mach sources (`../gnumach`) and configure it: +Find the path to your GNU Mach sources (`..`) and configure it: $ ../configure --prefix= @@ -96,7 +96,7 @@ into a bug when you configure and run make below. If that is the case, run "rm $ cd gnumach-build $ rm -rf * -Find the path to your GNU Mach sources (`../gnumach`) and configure it: +Find the path to your GNU Mach sources (`..`) and configure it: $ ../configure -- cgit v1.2.3 From 3e8cd4e4f6cf824e79e7eedf4af4d95f020f3e18 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:51:47 -0400 Subject: mentioned why header files must be installed. --- microkernel/mach/gnumach/building.mdwn | 7 +++++-- 1 file changed, 5 insertions(+), 2 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 015046e6..fcef1a24 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -54,7 +54,10 @@ You can now reboot your computer and enjoy the new kernel. Building GNU Mach requires a C compiler, a static 32 bit standard C library and your favourite flavor of awk (gawk) and GNU make. -### Installing only the Header Files +### Installing the Header Files First + +In order to build GNU Mach, you must build and install MIG, which requires that +you install the GNU Mach header files: First, you have to create the configuartion files: @@ -115,6 +118,6 @@ Optionally run the (tiny) test suite: You can then install and use `gnumach.gz`. -[TODO.] +[TODO] -- cgit v1.2.3 From 4583168b6fce700fc971aea3f0233d63c08d4cf2 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 17:58:11 -0400 Subject: Improved line wrapping for 2 pages --- microkernel/mach/gnumach/building.mdwn | 9 +++++---- microkernel/mach/mig/gnu_mig/building.mdwn | 30 +++++++++++++++++++++--------- 2 files changed, 26 insertions(+), 13 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index fcef1a24..0bd554b4 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -12,7 +12,8 @@ You can either use the git repository (see 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. +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/git/?group=hurd): +You can chose between getting the [sources from the developers' +RCS](http://savannah.gnu.org/git/?group=hurd): $ git clone git://git.savannah.gnu.org:/srv/git/hurd/mig.git -... 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): +... 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 @@ -20,7 +23,9 @@ The unpacked source tree is around 1 MiB, and the build tree also is around 1 Mi ### Preparing for the Build -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: +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 @@ -35,15 +40,19 @@ 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. +You can then install / distribute the _.deb_ file which will drop out one +directory above the current one. ## On non-Debian Systems: ### Preparing for the Build -Building the Mach Interface Generator requires a C compiler, a standard 32 bit C library (with corresponding header files) and your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. +Building the Mach Interface Generator requires a C compiler, a standard 32 bit +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/gnumach/building]] about how to do that, then come back here. ### Building and Installing @@ -57,7 +66,9 @@ The Mach Interface Generator should be built in a subdirectory: $ 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: +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 ../configure @@ -71,7 +82,8 @@ Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our $ make all install -To make your _mig_ binary easily available, you should append something like the following to e.g. your _~/.bash\_profile_: +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 -- cgit v1.2.3 From 2500a001957eab720d190bf5f53abd3214fe91b7 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 18:18:22 -0400 Subject: improved some wording --- microkernel/mach/gnumach/building.mdwn | 16 ++++++++-------- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 2 files changed, 9 insertions(+), 9 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 0bd554b4..8284639b 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -52,7 +52,7 @@ You can now reboot your computer and enjoy the new kernel. ### Preparing for the Build -Building GNU Mach requires a C compiler, a static 32 bit standard C library and +Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library and your favourite flavor of awk (gawk) and GNU make. ### Installing the Header Files First @@ -60,7 +60,7 @@ your favourite flavor of awk (gawk) and GNU make. In order to build GNU Mach, you must build and install MIG, which requires that you install the GNU Mach header files: -First, you have to create the configuartion files: +First, create the configuartion files: $ cd gnumach $ autoreconf --install @@ -84,9 +84,9 @@ Install the header files into e.g. `~/gnu/include/`: ### Building and Installing -Building GNU Mach requires you to have the Mach Interface Generator installed. -See [[building_MIG|mig/gnu_mig/building]] about how to do that, then come back -here. +After you've already installed the header files (above), as well as the the +Mach Interface Generator, you may finish building GNU Mach. (See +[[building_MIG|mig/gnu_mig/building]], then come back here.) GNU Mach should be built in a subdirectory create it if you have not already. @@ -94,8 +94,8 @@ GNU Mach should be built in a subdirectory create it if you have not already. $ cd gnumach-build If you previously ran ../configure for installing the header files, you may run -into a bug when you configure and run make below. If that is the case, run "rm --rf *" in the _build_ directory, and reconfigure. +into a bug when you configure and run make below. If that is the case, empty +the _build_ directory, and reconfigure. $ cd gnumach-build $ rm -rf * @@ -117,7 +117,7 @@ Optionally run the (tiny) test suite: $ make check -You can then install and use `gnumach.gz`. +You can now install and use `gnumach.gz`. [TODO] diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index f21d504e..6d17e7ef 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -52,7 +52,7 @@ 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. +[[building GNU Mach|mach/gnumach/building]] about how to do that, then come back here. ### Building and Installing -- cgit v1.2.3 From 02524ab022cb7a26c510d97e25cc3bb12998ff6f Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 3 Aug 2011 23:05:18 +0200 Subject: mig/building: Refer to the correct Git repo listing, not the dummy --- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 6d17e7ef..1712e990 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -6,7 +6,7 @@ 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/git/?group=hurd): +RCS](http://git.savannah.gnu.org/cgit/hurd/): $ git clone git://git.savannah.gnu.org:/srv/git/hurd/mig.git -- cgit v1.2.3 From a66b021e27e1608d192a61cd10027e3d0f5ca522 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:00:35 -0400 Subject: Fixed ../configure options issue/bug --- microkernel/mach/gnumach/building.mdwn | 28 +++++----------------------- 1 file changed, 5 insertions(+), 23 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 8284639b..eb3e0819 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -72,11 +72,11 @@ GNU Mach and its headers should be built in a subdirectory: Find the path to your GNU Mach sources (`..`) and configure it: - $ ../configure --prefix= + $ ../configure -Use the --host flag on 64 bit systems: +Use the --host flag and some options on 64 bit systems: - $ ../configure --prefix= --host=i686-unknown-linux-gnu + $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --host=i686-unknown-linux-gnu Install the header files into e.g. `~/gnu/include/`: @@ -88,26 +88,8 @@ After you've already installed the header files (above), as well as the the Mach Interface Generator, you may finish building GNU Mach. (See [[building_MIG|mig/gnu_mig/building]], then come back here.) -GNU Mach should be built in a subdirectory create it if you have not already. - - $ mkdir gnumach-build - $ cd gnumach-build - -If you previously ran ../configure for installing the header files, you may run -into a bug when you configure and run make below. If that is the case, empty -the _build_ directory, and reconfigure. - - $ cd gnumach-build - $ rm -rf * - -Find the path to your GNU Mach sources (`..`) and configure it: - - $ ../configure - -If you are building on a 64 bit system, do the following instead: - - $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' - $ ../configure --host=i686-unknown-linux-gnu +GNU Mach should be built in the subdirectory created above. If you've cleared +your directory since then, you'll need to rerun the configure script. Build the kernel image: -- cgit v1.2.3 From 57b19ed57280f4642320dcc2b36c8ffe3b28f225 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:09:37 -0400 Subject: no need to "find" what's under your nose --- microkernel/mach/gnumach/building.mdwn | 2 +- microkernel/mach/mig/gnu_mig/building.mdwn | 4 ++-- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index eb3e0819..4c7cee26 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -70,7 +70,7 @@ GNU Mach and its headers should be built in a subdirectory: $ mkdir gnumach-build $ cd gnumach-build -Find the path to your GNU Mach sources (`..`) and configure it: +Run configure: $ ../configure diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 1712e990..031a9b3f 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -67,8 +67,8 @@ The Mach Interface Generator should be built in a subdirectory: $ 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: +you now intend to install the Mach Interface Generator (_~/gnu_), and run +configure: $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure -- cgit v1.2.3 From 4c9e4221fdca00de9a0a8918dacc858819d8ca0c Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:12:03 -0400 Subject: generalize mig install instructions --- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 031a9b3f..673dcacf 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -34,7 +34,7 @@ specified by the source mig package: Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): - $ cd mig-1.3.1.99 + $ cd mig-X.X.X.XX Start the build process: -- cgit v1.2.3 From 32bef600e8063282f5077b08a69f63cc0eb9d591 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:14:09 -0400 Subject: missed a spot --- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 673dcacf..9a83e367 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -32,7 +32,7 @@ specified by the source mig package: ### Building and Installing ... a _.deb_ file -Change into the directory with the downloaded / unpacked MIG sources (_mig-1.3.1.99_): +Change into the directory with the downloaded / unpacked MIG sources (_mig-SomeVersionNumber): $ cd mig-X.X.X.XX -- cgit v1.2.3 From af52b8b7b4f3c096fd8abed7e901b57f07c419a2 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:30:37 -0400 Subject: Actually, we need '--prefix='. --- microkernel/mach/gnumach/building.mdwn | 4 ++-- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 2 files changed, 3 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 4c7cee26..f4c59d9f 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -72,11 +72,11 @@ GNU Mach and its headers should be built in a subdirectory: Run configure: - $ ../configure + $ ../configure --prefix= Use the --host flag and some options on 64 bit systems: - $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --host=i686-unknown-linux-gnu + $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu Install the header files into e.g. `~/gnu/include/`: diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 9a83e367..d5268221 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -71,7 +71,7 @@ you now intend to install the Mach Interface Generator (_~/gnu_), and run configure: $ GNU=~/gnu - $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure + $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" The --host flag is necessary if you are building on a 64 bit machine: -- cgit v1.2.3 From e0f350c7d6e3af901097e43fe2c1bc0efb237f60 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Wed, 3 Aug 2011 19:45:28 -0400 Subject: rename build directories to 'build' --- microkernel/mach/gnumach/building.mdwn | 4 ++-- microkernel/mach/mig/gnu_mig/building.mdwn | 4 ++-- 2 files changed, 4 insertions(+), 4 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index f4c59d9f..490c5497 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -67,8 +67,8 @@ First, create the configuartion files: GNU Mach and its headers should be built in a subdirectory: - $ mkdir gnumach-build - $ cd gnumach-build + $ mkdir build + $ cd build Run configure: diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index d5268221..4d4be660 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -63,8 +63,8 @@ First, generate the configuration files: The Mach Interface Generator should be built in a subdirectory: - $ mkdir mig-build - $ cd mig-build + $ mkdir build + $ cd 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 run -- cgit v1.2.3 From 9441f7dc189d8489f13b9072b866aa75f9409d0f Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 4 Aug 2011 02:43:29 +0200 Subject: mach/building: Rearrange bit about installing header files Instead of treating all the build preparations as part of the header install, make them part of the general build instructions; and only separately mention the specific bit about actually installing the headers. This should make the overall build process easier to follow; and also makes it clearer which bit can be left out if installing the headers is not necessary. --- microkernel/mach/gnumach/building.mdwn | 10 ++++------ 1 file changed, 4 insertions(+), 6 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 490c5497..5f53d83d 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -55,11 +55,6 @@ You can now reboot your computer and enjoy the new kernel. Building GNU Mach requires a C compiler, a _static_ 32 bit standard C library and your favourite flavor of awk (gawk) and GNU make. -### Installing the Header Files First - -In order to build GNU Mach, you must build and install MIG, which requires that -you install the GNU Mach header files: - First, create the configuartion files: $ cd gnumach @@ -78,7 +73,10 @@ Use the --host flag and some options on 64 bit systems: $ CPP='gcc -m32 -E -x c -undef -ansi' CC='gcc -m32' LD='ld -melf_i386' ../configure --prefix= --host=i686-unknown-linux-gnu -Install the header files into e.g. `~/gnu/include/`: +### Installing the Header Files First + +In order to build GNU Mach, you must build and install MIG, which requires that +you install the GNU Mach header files, for example into `~/gnu/include/`: $ make DESTDIR=~/gnu install-data -- cgit v1.2.3 From 358bc1d0e781b7237b2fee394f7fae2bfcd7b078 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 4 Aug 2011 07:14:40 +0200 Subject: mach/building: Reword for clarity --- microkernel/mach/gnumach/building.mdwn | 39 ++++++++++++++---------------- microkernel/mach/mig/gnu_mig/building.mdwn | 25 +++++++++---------- 2 files changed, 30 insertions(+), 34 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 5f53d83d..b513d52f 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -12,7 +12,7 @@ You can either use the git repository (see Preparing for the Build -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: +Building MIG requires the *build-essential* and *fakeroot* packages, +and some additional dependencies specified by the mig source package: # apt-get install build-essential fakeroot # apt-get build-dep mig ### Building and Installing ... a _.deb_ file -Change into the directory with the downloaded / unpacked MIG sources (_mig-SomeVersionNumber): +Change into the directory with the downloaded / unpacked MIG sources: $ cd mig-X.X.X.XX @@ -40,15 +39,15 @@ 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. +This will create a _.deb_ package in the parent directory, +which you can then install on your system. ## On non-Debian Systems: ### Preparing for the Build Building the Mach Interface Generator requires a C compiler, a standard 32 bit -C library (with corresponding header files) and your favourite flavor of awk +C library (with corresponding header files), your favourite flavor of awk (gawk), yacc (bison), lex (flex) and make. Additionally, you need to have GNU Mach's header files installed. See @@ -61,24 +60,24 @@ First, generate the configuration files: $ cd mig $ autoreconf --install -The Mach Interface Generator should be built in a subdirectory: +The Mach Interface Generator has to be built in a separate build directory: $ mkdir build $ cd 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 run +Find the base directory where you installed GNU Mach's header files and where +you now intend to install the Mach Interface Generator (e.g. _~/gnu_), and run configure: $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" -The --host flag is necessary if you are building on a 64 bit machine: +If you are building on a 64 bit machine, you need to add a --host option: $ GNU=~/gnu $ TARGET_CPPFLAGS=-I"$GNU"/include ../configure --prefix="$GNU" --host=i686-unknown-linux-gnu -Build and install the Mach Interface Generator into _$GNU_, i.e. _~/gnu/_ in our example: +Build and install the Mach Interface Generator into _$GNU_ (i.e. _~/gnu/_ in our example): $ make all install -- cgit v1.2.3 From b9ba15c091304bb033ca26036cf6a96819b0b602 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 4 Aug 2011 09:34:13 +0200 Subject: mach/building: Fix Git repo URL here as well --- microkernel/mach/gnumach/building.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index b513d52f..ebf0e1d7 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -8,7 +8,7 @@ enabled) is around 50 MiB. ## Getting the Source Code -You can either use the git repository (see ), +You can either use the git repository (see ), $ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git -- cgit v1.2.3 From 71b7e48fbe38f9238ee764513f4701b135d14fe8 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 4 Aug 2011 09:36:15 +0200 Subject: mach/building: Some more rewording Slipped through in last commit... --- microkernel/mach/gnumach/building.mdwn | 5 ++--- 1 file changed, 2 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index ebf0e1d7..0a9e328c 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -23,9 +23,8 @@ Please see the Debian [[running/debian/FAQ]] before using `apt-get source`. ### Preparing for the Build -Building GNU Mach requires the *build-essential* and *fakeroot* packages, their -dependencies and additional packages that are specified by the source gnumach -package: +Building GNU Mach requires the *build-essential* and *fakeroot* packages, +and some additional dependencies specified by the gnumach source package: # apt-get install build-essential fakeroot # apt-get build-dep gnumach -- cgit v1.2.3 From ef0baf74357b7db4c094c5103e3d17599f46b6d1 Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Thu, 4 Aug 2011 18:30:02 -0400 Subject: It's a good idea to backup prev. gnumach.gz --- microkernel/mach/gnumach/building.mdwn | 7 ++++--- 1 file changed, 4 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 0a9e328c..ecaae7f8 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -95,6 +95,7 @@ Optionally run the (tiny) test suite: $ make check -The resulting kernel binary can now be moved into place -(just copy `gnumach.gz`, typically to `/boot/gnumach.gz`), -so you can boot your system with the new kernel. +The resulting kernel binary can now be moved into place (just copy +`gnumach.gz`, typically to `/boot/gnumach.gz`), so you can boot your system +with the new kernel. It is a good idea to make a backup of the previously +installed binary, in case you need to recover. -- cgit v1.2.3 From 6ac278617dd6e5801577dc35cd9738579ecce8cb Mon Sep 17 00:00:00 2001 From: Andrew Engelbrecht Date: Thu, 4 Aug 2011 21:56:40 -0400 Subject: gnumach/build: expanded backup and install --- microkernel/mach/gnumach/building.mdwn | 15 +++++++++++---- 1 file changed, 11 insertions(+), 4 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index ecaae7f8..24a73608 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -95,7 +95,14 @@ Optionally run the (tiny) test suite: $ make check -The resulting kernel binary can now be moved into place (just copy -`gnumach.gz`, typically to `/boot/gnumach.gz`), so you can boot your system -with the new kernel. It is a good idea to make a backup of the previously -installed binary, in case you need to recover. +It's a good idea to make a backup of the previously installed kernel, in case +you can't boot using the new one. That way, you can restore it after booting +from a rescue media (or mounting the disk image used by your vm). + + # cp /boot/gnumach.gz /boot/gnumach.gz.bak + +GNU Mach can now be moved into place, typically `/boot/gnumach.gz`, so that you +can boot your system with the new kernel. + + # cp gnumach.gz /boot + -- cgit v1.2.3 From 8ae3e796208353b3191bccdacff608f47a87ecdd Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 10 Aug 2011 19:55:01 +0200 Subject: update memory limit --- microkernel/mach/gnumach/hardware_compatibility_list.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn index 6c984784..874f5f07 100644 --- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn +++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn @@ -29,7 +29,7 @@ Read about further [[ports]]. # Memory -GNU Mach will use a maximum of 1 GiB of RAM. If your system has more, +GNU Mach will use a maximum of 1.7 GiB of RAM. If your system has more, the surplus will silently be ignored. (In past times, this would hinder GNU Mach from booting at all, but this has been fixed, so you no longer need to apply GRUB's `uppermem` directive.) -- cgit v1.2.3 From 483c38fc1c9e83f186ab4bc57ac69f332ce002bd Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 15 Aug 2011 23:10:31 +0200 Subject: Add debugging tips & tricks --- microkernel/mach/gnumach/debugging.mdwn | 47 +++++++++++++++++++++++++++++++++ 1 file changed, 47 insertions(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 2f52adf8..8a5b1003 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -9,9 +9,56 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +Here are some hints to debug with GNU Mach + Mach has a built-in kernel debugger. [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). +First, make sure to enable it. Either by using a pre-packaged gnumach-image-something-dbg, or by passing --enable-kdb to the ./configure invocation. + +Then, reproduce the issue again. If something like a kernel trap happens, you will end up in the GNU Mach debugger. Otherwise, type control-alt-d to make Mach enter it by hand. + +The debugger has an extensive documentation on http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html , but a quick start is the following. + +To get the register values, type + +show registers + +To get a backtrace, type trace, which will print both function return addresses and function parameters, such as + +0x107cf1(8088488,5e,40000008,2aa008,0) +0x1071bc(0,0,0,0,0) +0x106831(24fe00,2000,b,800,0) + +Run the addr2line tool on the return addresses: + +addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 + +This will print the source code lines of the backtrace. + +To examine the backtrace of some given thread, use + +show all thread/u + +to get the whole listing of all tasks and threads. You can then use trace/t to trace a specific thread. + +Unfortunately, userland and kernelland use the same range of addresses, so one can not get userland traces easily. The Xen port uses different ranges, and in that case one can use trace/u to also get the userland trace. + +To examine a variable, use nm /boot/gnumach to get the address of the variable (e.g. 0x123400), and use + +x 0x123400 + +to read it. One can also write to it by using + +w 0x123400 + +Another interesting feature is watching a variable, by using + +watch 0x123400 + +and then type continue, to let Mach continue execution. The debugger will be entered again on any change in that variable. The watch is implemented in hardware, so it does not disturb or slow down execution at all. + + When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly [use GDB on the running -- cgit v1.2.3 From 9443eb281a8fa2207a5cc13bce9722dc500d2f35 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Mon, 15 Aug 2011 23:22:14 +0200 Subject: hint: use curses to copy/paste --- microkernel/mach/gnumach/debugging.mdwn | 2 ++ 1 file changed, 2 insertions(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 8a5b1003..596e4da0 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -18,6 +18,8 @@ First, make sure to enable it. Either by using a pre-packaged gnumach-image-some Then, reproduce the issue again. If something like a kernel trap happens, you will end up in the GNU Mach debugger. Otherwise, type control-alt-d to make Mach enter it by hand. +If you are running in kvm or qemu, it is convenient to use the curses frontend to be able to copy/paste. + The debugger has an extensive documentation on http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html , but a quick start is the following. To get the register values, type -- cgit v1.2.3 From 0606c86cb3869a8dd2c7f9b72af19e55b2312c2c Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sat, 27 Aug 2011 14:44:43 +0200 Subject: Add pv-grub config sample --- microkernel/mach/gnumach/ports/xen.mdwn | 24 ++++++++++++++++-------- 1 file changed, 16 insertions(+), 8 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index af431c92..1b967d38 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -79,20 +79,28 @@ Then use The current `hurd-modules` was built from the debian packages `hurd 20070606-2` and `libc0.3 2.6.1-1`. /!\ This means that when using this image, your GNU/Hurd system also needs to be a glibc version 2.6 or later-based one! +# `pv-grub` -# Miscellaneous +From Xen 4.0 on you can run the GNU Hurd directly using `pv-grub`, +without the need to [prepare a special bootstrap +image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an +initrd). -[[Internals]]. +Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use the following for instance: -[[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. + kernel = "/boot/pv-grub.gz" + memory = 256 + disk = ['phy:sda4,hda,w'] + extra = "(hd0,1)/boot/grub/menu.lst" + vif = [ '' ] +extra is now the path to the grub config file. -# `pv-grub` +# Miscellaneous -From Xen 4.0 on you'll be able to run the GNU Hurd directly using `pv-grub`, -without the need to [prepare a special bootstrap -image](http://youpibouh.thefreecat.org/hurd-xen/build_hurd-modules) (like an -initrd). +[[Internals]]. + +[[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. # Host-side Writeback Caching -- cgit v1.2.3 From 25e041c260fef647e9403883e96925010aa1ba5d Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sat, 27 Aug 2011 14:51:35 +0200 Subject: explain how to use part storeio --- microkernel/mach/gnumach/ports/xen.mdwn | 6 ++++++ 1 file changed, 6 insertions(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index 1b967d38..5b5399de 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -96,6 +96,12 @@ Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use extra is now the path to the grub config file. +In the menu.lst file, you will need the following notation for the gnumach root= parameter: + +root=part:2:device:hd0 + +to access the second partition of hd0, for instance. + # Miscellaneous [[Internals]]. -- cgit v1.2.3 From edd7d582fce7a52565efd3e404bb0419f7e34474 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Sat, 27 Aug 2011 15:39:25 +0200 Subject: document how to use parted storeio for /dev entries --- microkernel/mach/gnumach/ports/xen.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index 5b5399de..5fe73c06 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.mdwn @@ -96,12 +96,18 @@ Download http://youpibouh.thefreecat.org/hurd-xen/pv-grub.gz into /boot, and use extra is now the path to the grub config file. -In the menu.lst file, you will need the following notation for the gnumach root= parameter: +# Partitions + +You will need the following notation for the gnumach root= parameter: root=part:2:device:hd0 to access the second partition of hd0, for instance. +You will also need to use the parted storeio module for the /dev entries, for instance: + +settrans -fgap /dev/hd0s1 /hurd/storeio -T typed part:1:device:hd0 + # Miscellaneous [[Internals]]. -- cgit v1.2.3 From 016433b123ce4b60eee550dbdb7812ba623d16e7 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 30 Aug 2011 12:03:36 +0200 Subject: Minor tweaks. --- hurd/porting/system_api_limitations.mdwn | 2 +- hurd/running/debian/dhcp.mdwn | 7 +++ hurd/running/debian/patch_submission.mdwn | 7 +-- hurd/translator/pfinet/dhcp.mdwn | 37 ++++++-------- microkernel/mach/gnumach/building.mdwn | 11 +++++ microkernel/mach/gnumach/debugging.mdwn | 34 ++++++++----- microkernel/mach/mig/gnu_mig/building.mdwn | 11 +++++ .../mach/mig/gnu_mig/building/discussion.mdwn | 16 ++++++ microkernel/mach/mig/gnu_mig/discussion.mdwn | 6 --- open_issues/e2fsck_i_file_acl_hi.mdwn | 5 +- open_issues/libpthread_dlopen.mdwn | 14 +++--- open_issues/perl.mdwn | 13 ++--- open_issues/runit.mdwn | 57 +++++++++------------- open_issues/sync_but_still_unclean_filesystem.mdwn | 5 +- open_issues/virtualbox.mdwn | 30 ++++++------ source_repositories.mdwn | 17 ++++--- 16 files changed, 154 insertions(+), 118 deletions(-) create mode 100644 microkernel/mach/mig/gnu_mig/building/discussion.mdwn delete mode 100644 microkernel/mach/mig/gnu_mig/discussion.mdwn (limited to 'microkernel/mach') diff --git a/hurd/porting/system_api_limitations.mdwn b/hurd/porting/system_api_limitations.mdwn index 82327dde..1615ccc0 100644 --- a/hurd/porting/system_api_limitations.mdwn +++ b/hurd/porting/system_api_limitations.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 2010 Free Software +[[!meta copyright="Copyright © 2003, 2004, 2005, 2009, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable diff --git a/hurd/running/debian/dhcp.mdwn b/hurd/running/debian/dhcp.mdwn index f316981d..8d351aae 100644 --- a/hurd/running/debian/dhcp.mdwn +++ b/hurd/running/debian/dhcp.mdwn @@ -22,3 +22,10 @@ fatal. Debian GNU/Hurd doesn't currently execute's Debian standard `/etc/rcS.d/*` boot scripts, but has its own `/libexec/rc` script -- which integrates scripts from `/etc/rc.boot/` instead. + + +# Open Issues + + * [[!debbug 616290]] + + * [[Proper Hurdy DHCP support|hurd/translator/pfinet/dhcp]] diff --git a/hurd/running/debian/patch_submission.mdwn b/hurd/running/debian/patch_submission.mdwn index d2d10747..d2b7b776 100644 --- a/hurd/running/debian/patch_submission.mdwn +++ b/hurd/running/debian/patch_submission.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] If you fixed a Debian package which *FTBFS* (fails to build from source), you should submit the patch so that all users can profit from your work. diff --git a/hurd/translator/pfinet/dhcp.mdwn b/hurd/translator/pfinet/dhcp.mdwn index 79ed8966..456d0c84 100644 --- a/hurd/translator/pfinet/dhcp.mdwn +++ b/hurd/translator/pfinet/dhcp.mdwn @@ -1,31 +1,33 @@ -[[!tag open_issue_hurd]] +[[!meta copyright="Copyright © 2002, 2003, 2005, 2011 Free Software Foundation, +Inc."]] -According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. +[[!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]]."]]"""]] -[Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html) +[[!tag open_issue_hurd]] -The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). +[[Debian GNU/Hurd|running/debian]] has some script hackery to get +[[running/debian/DHCP]] going. --- 2011 +--- -The ISC dhcp client was ported, available in the isc-dhcp-client Debian package, [[http://bugs.debian.org/616290]]. +According to the following thread, no port should be needed since all the patches that have been applied, including the one concerning the thread. In fact, the thread finishes without concluding whether the patch has been applied or not. You can grab it in the thread, anyway. --- [[Main/ThadeuCascardo]] - 29 Sep 2005 +[Link to thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html) -No DHCP client has been ported to the Hurd yet. +The thread starts at Jan 4th 2005 until Jan 6th and is only retaken at April 14th in [this thread](http://lists.gnu.org/archive/html/bug-hurd/2005-01/msg00025.html). [This](http://mail.gnu.org/archive/html/help-hurd/2003-10/msg00016.html) thread on help-hurd has a little more info on what's still needed for DHCP. --- [[Main/GregBuchholz]] - 09 Oct 2003 - Found this [message](http://mail.gnu.org/archive/html/bug-hurd/2003-08/msg00045.html) about DHCP capabilities in the Hurd encouraging. --- [[Main/GregBuchholz]] - 03 Sep 2003 - * Tom Hart began a [discussion ](http://mail.gnu.org/pipermail/help-hurd/2002-October/006643.html) of 14 posts in Oct 2002. --- [[Main/GrantBow]] - 20 Oct 2002 - The beginnings of a DHCP translator is available in the Hurd sources on Savannah: [hurd/trans/pump.c](http://savannah.gnu.org/cgi-bin/viewcvs/hurd/hurd/trans/pump.c?rev=1.3&content-type=text/vnd.viewcvs-markup) Unfortunately our current TCP/IP stack, the pfinet translator, lacks support for the AF\_PACKET interface as well as sending packets with an IP address of 0.0.0.0. @@ -42,10 +44,3 @@ Neal Walfield on bug-hurd replies: > Anyone else know the status of getting these compiled and functional? We need to be able to send to the DHCP server with ip address 0.0.0.0. - --- [[Main/JoachimNilsson]] - 12 Nov 2002 - ---- - -[[Debian GNU/Hurd|running/debian]] has some script hackery to get -[[running/debian/DHCP]] going. diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index 24a73608..afcfac74 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -1,3 +1,14 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Building [[GNU_Mach|gnumach]] from Source If you want to build the [[GNU_Mach|gnumach]] kernel yourself instead of just using a diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn index 596e4da0..f657e7cc 100644 --- a/microkernel/mach/gnumach/debugging.mdwn +++ b/microkernel/mach/gnumach/debugging.mdwn @@ -9,7 +9,12 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -Here are some hints to debug with GNU Mach +Here are some hints to debug with GNU Mach. + +[[!toc levels=2]] + + +# Kernel Debugger Mach has a built-in kernel debugger. [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html). @@ -20,27 +25,25 @@ Then, reproduce the issue again. If something like a kernel trap happens, you wi If you are running in kvm or qemu, it is convenient to use the curses frontend to be able to copy/paste. -The debugger has an extensive documentation on http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html , but a quick start is the following. - To get the register values, type -show registers + show registers To get a backtrace, type trace, which will print both function return addresses and function parameters, such as -0x107cf1(8088488,5e,40000008,2aa008,0) -0x1071bc(0,0,0,0,0) -0x106831(24fe00,2000,b,800,0) + 0x107cf1(8088488,5e,40000008,2aa008,0) + 0x1071bc(0,0,0,0,0) + 0x106831(24fe00,2000,b,800,0) Run the addr2line tool on the return addresses: -addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 + $ addr2line -i -f -e /boot/gnumach 0x107cf1 0x1071bc 0x106831 This will print the source code lines of the backtrace. To examine the backtrace of some given thread, use -show all thread/u + show all thread/u to get the whole listing of all tasks and threads. You can then use trace/t to trace a specific thread. @@ -48,25 +51,28 @@ Unfortunately, userland and kernelland use the same range of addresses, so one c To examine a variable, use nm /boot/gnumach to get the address of the variable (e.g. 0x123400), and use -x 0x123400 + x 0x123400 to read it. One can also write to it by using -w 0x123400 + w 0x123400 Another interesting feature is watching a variable, by using -watch 0x123400 + watch 0x123400 and then type continue, to let Mach continue execution. The debugger will be entered again on any change in that variable. The watch is implemented in hardware, so it does not disturb or slow down execution at all. +# GDB in QEMU When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly [use GDB on the running kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48). +# Code Inside the Kernel + Alternatively you can use an approach like this one: add the following code snippet to `device/ds_routines.c`'s `ds_device_open` function, right at the top of the function, and modify the code as needed. @@ -105,6 +111,8 @@ This is especially useful if you need to manually trigger some stuff inside the running kernel, as with the *D1* example. +## Writing to the Screen Buffer + If you're doing real low level debugging, you might want to put variations of the following snipped into the code, this code will write a `#` character at line `[LINE]`, column `[COLUMN]` on the screen: @@ -118,6 +126,8 @@ some place when running the kernel inside QEMU, as QEMU somehow decides not to update its display buffer anymore under certain conditions. +# Halting the CPU and Examining Registers + IRC, freenode, #hurd, 2011-07-14: one ugly trick i use when printf isn't available is to halt the diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index 759c1a84..cd588341 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -1,3 +1,14 @@ +[[!meta copyright="Copyright © 2006, 2007, 2008, 2011 Free Software Foundation, +Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + # Building the Mach Interface Generator from Source If you want to build the Mach Interface Generator yourself instead of just diff --git a/microkernel/mach/mig/gnu_mig/building/discussion.mdwn b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn new file mode 100644 index 00000000..d7636158 --- /dev/null +++ b/microkernel/mach/mig/gnu_mig/building/discussion.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +# Non-cross-compiling + +[[!tag open_issue_mig]] + +[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] + diff --git a/microkernel/mach/mig/gnu_mig/discussion.mdwn b/microkernel/mach/mig/gnu_mig/discussion.mdwn deleted file mode 100644 index e5a4dea3..00000000 --- a/microkernel/mach/mig/gnu_mig/discussion.mdwn +++ /dev/null @@ -1,6 +0,0 @@ -# Builing MIG - -## Non-cross-compiling - -[[samuelthibault]] mentioned that I should make clear what compiler options, etc. are only needed if compiling on a 64 bit computer. However, I don't know if the --host=i686... option is needed, here and when making gnumach, in case there may be some other default on 32 bit computers? --[[sudoman]] - diff --git a/open_issues/e2fsck_i_file_acl_hi.mdwn b/open_issues/e2fsck_i_file_acl_hi.mdwn index f055babe..d03b733c 100644 --- a/open_issues/e2fsck_i_file_acl_hi.mdwn +++ b/open_issues/e2fsck_i_file_acl_hi.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -34,4 +34,5 @@ IRC, unknown channel, unknown date. k but it's always passive translator nodes -This is due to an erroneous read/write from e2fsck, see http://sourceforge.net/tracker/?func=detail&aid=3379227&group_id=2406&atid=102406 +This is due to an erroneous read/write from e2fsck, see +. diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0cd761f2..0d3628ec 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -15,7 +15,7 @@ IRC, OFTC, #debian-hurd, 2011-07-21. there's one known issue with pthreads you can't dlopen() it -[ if the main application is not already linked against it ] +... if the main application is not already linked against it. which also means you can't dlopen() a module which depends on it if the main application hasn't used -lpthread already @@ -43,12 +43,12 @@ The fix thus being: link the main application with -lpthread. The same symptom appears in an odd case, for instance: -buildd@hurd:~$ ldd /usr/bin/openjade - libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) - libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) - libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) - libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) -... + buildd@hurd:~$ ldd /usr/bin/openjade + libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) + libosp.so.5 => /usr/lib/libosp.so.5 (0x01044000) + libpthread.so.0.3 => /lib/libpthread.so.0.3 (0x01221000) + libnsl.so.1 => /lib/i386-gnu/libnsl.so.1 (0x01232000) + [...] openjade links against *both* libthreads and libpthread. The result is that libc early-initializes libthreads only, and thus libpthread is not early-initialized, diff --git a/open_issues/perl.mdwn b/open_issues/perl.mdwn index c7428cb5..45680328 100644 --- a/open_issues/perl.mdwn +++ b/open_issues/perl.mdwn @@ -10,16 +10,13 @@ License|/fdl]]."]]"""]] [[!meta title="Foster Perl programming"]] -A dependency loop in Debian GNU/Hurd currently leads to +[[!template id=note text="""**2011-08**. A dependency loop in Debian GNU/Hurd +currently leads to: *Could not perform immediate configuration on 'perl'*. +Easy workaround: -`Could not perform immediate configuration on 'perl'` - -Simply use - -`apt-get install perl perl-base -o APT::Immediate-Configure=false` - -to break the loop. + # apt-get install perl perl-base -o APT::Immediate-Configure=false +"""]] Resolve issues uncovered by Perl's test suite, and enable Hurd-specific diff --git a/open_issues/runit.mdwn b/open_issues/runit.mdwn index 6b336ef7..659b81ea 100644 --- a/open_issues/runit.mdwn +++ b/open_issues/runit.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2008, 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2008, 2009, 2011 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] [[!tag open_issue_porting]] @@ -26,36 +27,24 @@ Originally answered by Samuel Thibault: Usual issue with rpctrace: it does not support fork(). -I've checked a backtrace in gdb, got this: - - 0x0105af6c in mach_msg_trap () - at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 - -1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, - timeout=1000020, notify=0) at msg.c:110 - -2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, - timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 - -3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 - -4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 - -5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 - - -and main() shows up as: - - sig_unblock(sig_term); - - sig_unblock(sig_child); - - -> iopause(x, 2 +haslog, &deadline, &now); - - sig_block(sig_term); - - sig_block(sig_child); - + I've checked a backtrace in gdb, got this: + + 0x0105af6c in mach_msg_trap () + at /build/eglibc-jWVnRE/eglibc-2.13/build-tree/hurd-i386-libc/mach/mach_msg_trap.S:2 + 1 0x0105b769 in __mach_msg (msg=0x1024af8, option=258, send_size=0, rcv_size=40, rcv_name=140, + timeout=1000020, notify=0) at msg.c:110 + 2 0x01062251 in _hurd_select (nfds=2, pollfds=0x1024dc0, readfds=0x0, writefds=0x0, exceptfds=0x0, + timeout=0x1024bbc, sigmask=0x0) at hurdselect.c:324 + 3 0x0114427b in __poll (fds=0x1024dc0, nfds=2, timeout=1000020) at ../sysdeps/mach/hurd/poll.c:48 + 4 0x0804b770 in iopause (x=0x1024dc0, len=2, deadline=0x1024dd8, stamp=0x1024de8) at iopause.c:29 + 5 0x08048efc in main (argc=2, argv=0x1024e94) at runsv.c:543 + + and main() shows up as: + + sig_unblock(sig_term); + sig_unblock(sig_child); + -> iopause(x, 2 +haslog, &deadline, &now); + sig_block(sig_term); + sig_block(sig_child); So it simply looks like the known "signals don't interrupt select" bug. - diff --git a/open_issues/sync_but_still_unclean_filesystem.mdwn b/open_issues/sync_but_still_unclean_filesystem.mdwn index 8a0b1d49..c8a37169 100644 --- a/open_issues/sync_but_still_unclean_filesystem.mdwn +++ b/open_issues/sync_but_still_unclean_filesystem.mdwn @@ -33,6 +33,5 @@ Of course, [[hurd/translator/ext2fs]] is meant to be doing this to-disk synchronization internally upon translator shutdown, but evidently it doesn't in all cases. - Apparently diskfs simply does not set filesystem as readonly: - - http://lists.gnu.org/archive/html/bug-hurd/2011-08/msg00024.html +Apparently diskfs simply does not set filesystems as read-only: +. diff --git a/open_issues/virtualbox.mdwn b/open_issues/virtualbox.mdwn index 246313ff..9440284f 100644 --- a/open_issues/virtualbox.mdwn +++ b/open_issues/virtualbox.mdwn @@ -8,15 +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]]."]]"""]] -[[!meta title="xattr: extended attributes"]] - [[!tag open_issue_gnumach]] Running GNU Mach in VirtualBox crashes during initialization. IRC, freenode, #hurd, 2011-08-15 - HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once you see the Grub menu, turn off the debian hurd box. 3) Let the box boot normally, and wait for the error/crash/reboot. 4) The error/crash will happen twice and it's reboot automatically. The 3rd boot will success. + HowTo Reproduce: 1) Use `reboot` to reboot the system. 2) Once + you see the Grub menu, turn off the debian hurd box. 3) Let the box boot + normally, and wait for the error/crash/reboot. 4) The error/crash will + happen twice and it's reboot automatically. The 3rd boot will success. root@dhurd:/boot# addr2line -f -e gnumach-1.3.99-486-dbg-copy 0x106c93 0x1556a5 0x152c54 copyoutmsg @@ -28,8 +29,8 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:1289 is - movl $USER_DS,%eax /* use user data segment for accesses */ -=> mov %ax,%es + movl $USER_DS,%eax /* use user data segment for accesses */ + => mov %ax,%es State is @@ -66,14 +67,14 @@ IRC, freenode, #hurd, 2011-08-15 i386/i386/locore.S:527 is: -_return_from_kernel: -_kret_popl_gs: - popl %gs /* restore segment registers */ -_kret_popl_fs: - popl %fs -_kret_popl_es: -=> popl %es -_kret_popl_ds: + _return_from_kernel: + _kret_popl_gs: + popl %gs /* restore segment registers */ + _kret_popl_fs: + popl %fs + _kret_popl_es: + => popl %es + _kret_popl_ds: cs: 0x8 ds: 0x10 @@ -93,5 +94,6 @@ _kret_popl_ds: efl: 0x10216 looks again like a $USER_DS issue - what's interesting is that that one means that $USER_DS did load in %es fine at least once + what's interesting is that that one means that $USER_DS did load in + %es fine at least once and it's the reload that fails diff --git a/source_repositories.mdwn b/source_repositories.mdwn index df0242f0..5ac90b5e 100644 --- a/source_repositories.mdwn +++ b/source_repositories.mdwn @@ -1,5 +1,5 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009, 2010 Free Software Foundation, -Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2009, 2010, 2011 Free Software +Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -22,14 +22,17 @@ This page is meant to give some guidelines. Please use good sense or ask on * hurd.git -- Hurd meta package; no real content yet * [[hurd/glibc.git|glibc]] -- [[/glibc]] maintenance - * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]] ([[building|microkernel/mach/gnumach/building]]) - * hurd/hurd.git -- [[/Hurd]] ([[building|hurd/building]]) + * hurd/gnumach.git -- [[GNU Mach|microkernel/mach/gnumach]] + ([[microkernel/mach/gnumach/building]]) + * hurd/hurd.git -- [[/Hurd]] ([[hurd/building]]) * [[hurd/incubator.git|incubator]] -- the great next stuff * hurd/libpthread.git -- [[POSIX threading library|libpthread]] - * hurd/mig.git -- [[microkernel/mach/MIG]] ([[building|microkernel/mach/mig/gnu_mig/building]]) + * hurd/mig.git -- [[microkernel/mach/MIG]] + ([[microkernel/mach/mig/gnu_mig/building]]) * hurd/procfs.git -- [[hurd/translator/procfs]] - * hurd/unionfs.git -- -- [[hurd/translator/unionfs]] - * hurd/viengoos.git -- [[microkernel/Viengoos]] ([[building|microkernel/viengoos/building]]) + * hurd/unionfs.git -- [[hurd/translator/unionfs]] + * hurd/viengoos.git -- [[microkernel/Viengoos]] + ([[microkernel/viengoos/building]]) * hurd/web.git -- [[contributing/Web_pages]] -- cgit v1.2.3 From 3e7472b3d54853389cd8a17475901fbef976ef18 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 1 Sep 2011 09:27:33 +0200 Subject: IRC. --- hurd/subhurd/discussion.mdwn | 69 ++++ hurd/translator/discussion.mdwn | 25 ++ hurd/translator/procfs/jkoenig/discussion.mdwn | 23 ++ microkernel/discussion.mdwn | 24 ++ microkernel/mach/memory_object/discussion.mdwn | 24 ++ news/2011-q2-ps.mdwn | 33 ++ .../active_vs_passive_symlink_translator.mdwn | 44 +++ open_issues/clock_gettime.mdwn | 28 +- open_issues/code_analysis.mdwn | 7 + open_issues/glibc_init_first.mdwn | 78 ++++ open_issues/gnumach_memory_management.mdwn | 397 +++++++++++++++++++++ open_issues/hurd_101.mdwn | 38 ++ open_issues/libpthread_dlopen.mdwn | 30 +- open_issues/mach_tasks_memory_usage.mdwn | 49 ++- open_issues/mmap_crash_etc.mdwn | 95 +++++ open_issues/multiprocessing.mdwn | 37 +- open_issues/packaging_libpthread.mdwn | 5 +- open_issues/performance.mdwn | 4 + open_issues/performance/degradation.mdwn | 28 ++ .../performance/io_system/binutils_ld_64ksec.mdwn | 15 + .../performance/microkernel_multi-server.mdwn | 47 +++ open_issues/proc_server_proc_exception_raise.mdwn | 37 ++ open_issues/resource_management_problems.mdwn | 15 + .../io_accounting.mdwn | 49 +++ open_issues/sa_siginfo_sa_sigaction.mdwn | 49 ++- open_issues/sbcl.mdwn | 31 ++ open_issues/sendmsg_scm_creds.mdwn | 4 + open_issues/syslog.mdwn | 44 ++- open_issues/tty_activitiy_vs_disk_io.mdwn | 81 +++++ open_issues/user-space_device_drivers.mdwn | 36 ++ open_issues/wine.mdwn | 50 ++- open_issues/wine/rg6dx09G.patch | 116 ++++++ 32 files changed, 1598 insertions(+), 14 deletions(-) create mode 100644 hurd/subhurd/discussion.mdwn create mode 100644 hurd/translator/discussion.mdwn create mode 100644 microkernel/discussion.mdwn create mode 100644 microkernel/mach/memory_object/discussion.mdwn create mode 100644 open_issues/active_vs_passive_symlink_translator.mdwn create mode 100644 open_issues/glibc_init_first.mdwn create mode 100644 open_issues/hurd_101.mdwn create mode 100644 open_issues/mmap_crash_etc.mdwn create mode 100644 open_issues/performance/degradation.mdwn create mode 100644 open_issues/performance/microkernel_multi-server.mdwn create mode 100644 open_issues/proc_server_proc_exception_raise.mdwn create mode 100644 open_issues/resource_management_problems/io_accounting.mdwn create mode 100644 open_issues/sbcl.mdwn create mode 100644 open_issues/tty_activitiy_vs_disk_io.mdwn create mode 100644 open_issues/wine/rg6dx09G.patch (limited to 'microkernel/mach') diff --git a/hurd/subhurd/discussion.mdwn b/hurd/subhurd/discussion.mdwn new file mode 100644 index 00000000..3449edcd --- /dev/null +++ b/hurd/subhurd/discussion.mdwn @@ -0,0 +1,69 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-08-10 + + < braunr> youpi: aren't sub-hurds actually called "neighbor hurds" ? + < youpi> no idea + < braunr> i also don't understand the recursive property + < youpi> a user can run a subhurd + < neal> braunr: What don't you understand? + < youpi> a user in a subhurd can run a subhurd + < youpi> etc + < braunr> i'm not sure it's really recursive + < neal> youpi: At some point it was observed that you don't strictly + require any resources from the "parent" Hurd. + < neal> youpi: i.e., you could have two Hurds running "directly" on Mach + < youpi> sure + < neal> youpi: Hence neighbor rather than sub + < youpi> but you need to be root for that + < youpi> or else your subhurd can't do much + < neal> you need to have been authorized to use the required resouces + < youpi> which is about the same :) + < neal> depends how they are delegated + < youpi> that's still asking root for something + < neal> if you say so + < youpi> which is most probably not the default + < braunr> well, either you depend on the parent to do things on your + behalf, or you directly have some privileged ports + < braunr> i'd agree with youpi that it's pretty much having root access at + some point + < youpi> and usually you don't have privileged ports by default :) + < braunr> but we don't need to restrict the presentation to user only sub + hurds + < braunr> people don't mind switching to root on their desktops + < braunr> which is one of the reasons they ask "what does the hurd really + bring me today ?" + < braunr> but being able to run truely separate hurds or recursive hurds is + something nice most OSes can't do easily + < youpi> switching to root becomes a *pain* when you have to do it 1 every + two commands + < braunr> yes sure, but some people might just say you're clumsy :x + < neal> The question is: can I start a sub-hurd from within another hurd + that survives the parent's hurd exiting? The answer is yes. The reason + is that the sub-hurd can be constructed in such a way that it does not + rely on the parent. In this case, the parent does not necessarily + subjugate the sub-hurd. Hence the name. + < braunr> but that's out of the scope of the discussion + < antrik> using the traditional, root only mechanism, neighbour-hurd is + indeed a more appropriate term. apart from the initial terminal being + proxied to the parent system by the boot program, they are really equal + < antrik> with zhengda's work on non-root subhurds, you rely on various + proxies in the parent system to access privileged resources; so subhurd + is indeed a more appropriate term in this case + < antrik> (not only non-root subhurds in fact... when using any of the + proxies, such as the network multiplexer -- even if still running as + root...) + < youpi> antrik: you could still give a com0 port as terminal + < antrik> I don't think that's actually supported in the boot + program... but it doesn't really matter, as you don't really need the + terminal anyways -- you can always log in through the network diff --git a/hurd/translator/discussion.mdwn b/hurd/translator/discussion.mdwn new file mode 100644 index 00000000..e038ba84 --- /dev/null +++ b/hurd/translator/discussion.mdwn @@ -0,0 +1,25 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-08-25: + + < frhodes> how can I replace an existing running server with a new one + without rebooting? + < antrik> frhodes: depends. if other critical things depend on it, you + can't. there is no mechanism to serialize and pass on the open sessions + < antrik> in some situations, you can orphan the old translator while + starting a new one, so the previous clients will stay with the old one + while new one will get the new one + < antrik> obviously that only works for things that aren't exclusive by + nature + < antrik> in some cases, you might even be able simply to remove the old + translator... but obviously only for non-critical stuff :-) diff --git a/hurd/translator/procfs/jkoenig/discussion.mdwn b/hurd/translator/procfs/jkoenig/discussion.mdwn index 64e3776e..01bbea42 100644 --- a/hurd/translator/procfs/jkoenig/discussion.mdwn +++ b/hurd/translator/procfs/jkoenig/discussion.mdwn @@ -184,3 +184,26 @@ IRC, freenode, #hurd, 2011-07-22 status is 644 though but status contains information which anyone can ask to the proc server anyway, I think. + + +# `/proc/mounts`, `/proc/$pid/mounts` + +IRC, freenode, #hurd, 2011-07-25 + + < pinotree> jkoenig: btw, what do you think about providing empty + /proc/mounts and /proc/$pid/mounts files? + < jkoenig> pinotree, I guess one would have to evaluate the consequences + wrt. existing use cases (in other words, "I have absolutely no clue + whatsoever about whether that would be desirable" :-) + < jkoenig> pinotree, the thing is, an error message like "/proc/mounts: No + such file or directory" is rather explicit, whereas errors which would be + caused by missing data in /proc/mounts would maybe be harder to track + < braunr> this seems reasonable though + < braunr> there already are many servers with e.g. grsecurity or chrooted + environments where mounts is empty + < pinotree> well, currently we also have an empty mtab + < braunr> pinotree: but what do you need that for ? + < braunr> pinotree: the init system ? + < pinotree> and the mnt C api already returns no entries (or it bails out, + i don't remember) + < pinotree> not a strict need diff --git a/microkernel/discussion.mdwn b/microkernel/discussion.mdwn new file mode 100644 index 00000000..a5a73e18 --- /dev/null +++ b/microkernel/discussion.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +IRC, freenode, #hurd, 2011-07-26: + + < antrik> Tekk_`: regarding microkernels: the basic idea, and really the + *only* fundamental difference, is that they isolate things in separate + address spaces. everything else goes back to this. + < antrik> benefits from the isolation generally fall into two groups: more + robustness (main focus of Minix3), and more flexibility (main focus of + Hurd) + < antrik> while it might also encourage some other good design choices, + these are secondary effects: such choices can also be implemented in a + monolithic architecture -- and not necessarily harder. just less obvious + in some cases... diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn new file mode 100644 index 00000000..a006429b --- /dev/null +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -0,0 +1,24 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_gnumach]] + +IRC, freenode, #hurd, 2011-08-05 + + < neal> braunr: For instance, memory objects are great as they allow you to + specify the mapping policy in user space. + < neal> braunr: But, the policy for determining the eviction order is + realized by Mach + < neal> braunr: And user-space has no control + < braunr> are you referring to the page cache lru approximation and stuff + like resource containers ? + < neal> I'm not sure what you mean by page cache lru appoximateion + < braunr> the kernel eviction policy :) + < neal> that's an implementation detail diff --git a/news/2011-q2-ps.mdwn b/news/2011-q2-ps.mdwn index cbf039b0..14578e83 100644 --- a/news/2011-q2-ps.mdwn +++ b/news/2011-q2-ps.mdwn @@ -95,4 +95,37 @@ slashdot and phoronix did some [performance tests of the Hurd][phorperf], [phorperf]: http://www.phoronix.com/scan.php?page=article&item=debian_gnu_hurd&num=1 +--- + +IRC, freenode, #hurd, 2011-08-24: + + < ArneBab> hurd related: I now think you were right, antrik: the hurd + rumors don’t belong into the news (tschwinge) + < antrik> ArneBab: you mean the postscriptum as a whole, or just the wild + rumours part?... + < ArneBab> the whole PS + < ArneBab> it should rather go into a blog post + < ArneBab> (in the wiki) + < antrik> hm... I don't think I agree + < ArneBab> why? + < antrik> apparently there is a number of people following the news now, + and apparently many of them misread some statements... it makes sense to + use the same channel for clarifying them I'd say + < ArneBab> hm, ok + < ArneBab> how would you select the part to include? + < antrik> roughly speaking, I'd include everything that actually relates to + the previous news that were misunderstood + < antrik> and drop all unrelated speculations that popped up + < antrik> BTW, it *might* be useful perhaps to actually update the original + news posting with the clarifications?... + < ArneBab> we can’t do that without breaking some peoples RSS feeds + < antrik> note that there is another aspect to consider: the fact that + several news sites picked it up is indeed genuine news by itself... + < ArneBab> that’s right, yes + < antrik> will it really break anything? from what I heard so far it just + means they will see the posting as new again, which would actually make + sense in this case... + < antrik> but I don't insist if you think it's too risky :-) + < antrik> just an idea + --> diff --git a/open_issues/active_vs_passive_symlink_translator.mdwn b/open_issues/active_vs_passive_symlink_translator.mdwn new file mode 100644 index 00000000..cbd9b077 --- /dev/null +++ b/open_issues/active_vs_passive_symlink_translator.mdwn @@ -0,0 +1,44 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation open_issue_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + +Set an *active* (not *passive*) `/hurd/symlink` translator on a node. + + < antrik> that's strange: the file doesn't look like a symlink in ls output + -- but it behaves like one... + < antrik> using firmlink instead of symlink yields less confusing + results... + < gg0> how does it behaves like one? + < antrik> perhaps the symlink mechanism only fully works for a passive + symlink translator, not an active one + < antrik> gg0: if you access it, you actually get the linked file contents + < antrik> it's only ls that's confused + < antrik> it might be because ls -l uses O_NOFOLLOW, which results in + O_NOTRANS, so it sees the original file contents + < gg0> stat says it's still 12264 bytes + < antrik> stat also seems to use NOFOLLOW + < antrik> wc will show the "correct" size + < gg0> ok + < antrik> if you set it as passive translator, it works as expected... but + then you better don't forget removing it, as it won't go away after a + reboot :-) + < antrik> but as I said, you can just ignore the weirdness -- or use + firmlink instead + < antrik> the thing is, if symlink is set as a passive translator, the + filesystem handles it specially, so it really looks like a symlink to + programs using NOFOLLOW. that's not the case with an active symlink... so + programs using NOFOLLOW simply do not see the active symlink at all + < antrik> firmlink OTOH ignores NOFOLLOW, so you always see the linked-to + file + + * [[hurd/translator/short-circuiting]] diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index bba0d171..c06edc9b 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -12,8 +12,30 @@ License|/fdl]]."]]"""]] [[!tag open_issue_glibc open_issue_gnumach]] -Missing clock_gettime(CLOCK_MONOTONIC) (e.g. for iceweasel) +Missing `clock_gettime(CLOCK_MONOTONIC)` (e.g. for iceweasel) -It could be a mere matter of extending the mappable clock: add it to mapped_time_value_t in gnumach, handle it in gnumach/kern/mach_clock.c, and make clock_gettime use it. +It could be a mere matter of extending the mappable clock: add it to +`mapped_time_value_t` in gnumach, handle it in `gnumach/kern/mach_clock.c`, and +make `clock_gettime` use it. -BTW, also make gettimeofday() use it, since it's way more efficient and some applications assume that it is. +BTW, also make `gettimeofday()` use it, since it's way more efficient and some +applications assume that it is. + +What about adding a nanosecond-precision clock, too? --[[tschwinge]] + +IRC, freenode, #hurd, 2011-08-26: + + < pinotree> youpi: thing is: apparently i found a simple way to have a + monotonic clock as mmap-able device inside gnumach + < pinotree> currently, in kern/mach_clock.c there's a variable 'time', + which gets increased on clock interrupt, and optionally modified by + host_set_time + < pinotree> () + < pinotree> if i add a new variable next to it, only increasing it on + interrupt but not modifying it at all otherwise, would that give me a + monotonic clock? + < pinotree> at least on sme basic tests i did, it seems it could work that + way + < youpi> yes, it should work + < braunr> sure + < youpi> and that's the way I was considering implementing it diff --git a/open_issues/code_analysis.mdwn b/open_issues/code_analysis.mdwn index ab90a6b6..552cd2c9 100644 --- a/open_issues/code_analysis.mdwn +++ b/open_issues/code_analysis.mdwn @@ -27,6 +27,13 @@ analysis|performance]], [[formal_verification]], as well as general * [[!wikipedia List_of_tools_for_static_code_analysis]] + * [Cppcheck](http://sourceforge.net/apps/mediawiki/cppcheck/) + + For example, [Debian's hurd_20110319-2 + package](http://qa.debian.org/daca/cppcheck/sid/hurd_20110319-2.html) + (Samuel Thibault, 2011-08-05: *I had a look at those, some are spurious; + the realloc issues are for real*). + * Coccinelle * diff --git a/open_issues/glibc_init_first.mdwn b/open_issues/glibc_init_first.mdwn new file mode 100644 index 00000000..774b7828 --- /dev/null +++ b/open_issues/glibc_init_first.mdwn @@ -0,0 +1,78 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_glibc]] + +IRC, freenode, #hurd, 2011-07-22 + + [additional init-first.c patch] + < tschwinge> civodul: The only thing I wonder about: Roland also once had + done similar changes, which I then found they didn'T work with GCC 4.1, + and backed them out in 08f53ee9d265ffdc7e0affd6acf346cceeb65559 and fixed + the issue differently in d8d27e633a7860b37fd2e3142822b640a066cc0f (and + e17cef66140d4c97710ea88bd8d12612799e1e0f). Have you reviewed this? + < tschwinge> That's in the Savannah glibc repository. + < tschwinge> And this has been in 2007, four years ago. I don't remember + all the details. + < tschwinge> And here is quite a good summary of this stuff, from + init-first.c: + < tschwinge> /* XXX This is all a crock and I am not happy with it. + < tschwinge> This poorly-named function is called by static-start.S, + < civodul> braunr: thanks; i must admit it took me a while to figure it out + ;-) + < tschwinge> which should not exist at all. */ + < tschwinge> civodul: I can imagine... :-/ + < civodul> tschwinge: re Roland's changes, that's weird; i plan to try to + reinstate his change and see if it works + < civodul> now, i won't test with GCC 4.1... + < tschwinge> Yeah... + < tschwinge> I'm happy if it works with 4.4 onwards. + < tschwinge> civodul: And it's safe (in GCC terms) to write to ``* ((void + **) __builtin_frame_address (0) + 1)'', and similar? + < tschwinge> Or should we be coding this few stuff in assembly? + < civodul> tschwinge: well, we should add a compile-time assertion for + __builtin_return_address (0) == *((void**)__builtin_frame_address (0) + + 1) + < civodul> (i think GCC can figure it out at compile-time) + < civodul> but on IA32 it should always be true + < civodul> what's the name of glibc's compile-time assert macro already? + < tschwinge> I wonder whether that might interfere with some of GCC's + optimizations? + < civodul> what? + < tschwinge> Well, it seems unclean for me to be modifying a function's + return address from within C code. + < tschwinge> civodul: I added a verify.h in the t/verify.h branch. But + people didn't really like it too much. They rather wanted to directly + inline the array[(cond)?1:-1] code. + < civodul> ok + < civodul> i remember a debate about Gnulib's verify.h + < civodul> i thought something comparable had landed eventually + < tschwinge> civodul: Oh, maybe I missed it. + < tschwinge> civodul: In init-first.c:init, what about the usage of + data[-1] in the else path (not using cthreads) -- is that good as-is? + < civodul> tschwinge: oooh, it probably needs to fixed too + < civodul> but i haven't reached that point yet ;-) + * civodul tries to cross-bootstrap GNU from scratch + < tschwinge> civodul: I'd be happy to learn what was wrong with Roland's + original idea of fixing this. Or perhaps this was a GCC 4.1 bug? Or + perhaps GCC was inlining to much, and then got confused with frames and + return addresses? + < civodul> tschwinge: Roland's change looks good to me, so it could have + been a GCC bug + < civodul> tschwinge: OK to commit the patch to t/init-first.c (with both + data[-1] replaced)? + < tschwinge> civodul: OK, if you are confident that it works with GCC 4.4 + onwards. If yes, please add your changelog snippet to .topmsg, and also + add a not that Roland's original code may in fact have been fine, and we + may have hit a compiler bug. + < civodul> tschwinge: OK, will do + < civodul> tschwinge: though regarding Roland's change, i'd prefer to + actually test and see + < tschwinge> civodul: Thanks! diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index 448aafcc..a728fc9d 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -923,3 +923,400 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. 20 years ago but it's a source of deadlock Indeed. I'll won't use kmem_alloc_pageable. + + +# IRC, freenode, #hurd, 2011-08-09 + + < braunr> mcsim: what's the "bug related to MEM_CF_VERIFY" you refer to in + one of your commits ? + < braunr> mcsim: don't use spin_lock_t as a member of another structure + < mcsim> braunr: I confused with types in *_verify functions, so they + didn't work. Than I fixed it in the commit you mentioned. + < braunr> in gnumach, most types are actually structure pointers + < braunr> use simple_lock_data_t + < braunr> mcsim: ok + < mcsim> > use simple_lock_data_t + < mcsim> braunr: ok + < braunr> mcsim: don't make too many changes to the code base, and if + you're unsure, don't hesitate to ask + < braunr> also, i really insist you rename the allocator, as done in x15 + for example + (http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=vm/kmem.c), instead of + a name based on mine :/ + < mcsim> braunr: Ok. It was just work name. When I finish I'll rename the + allocator. + < braunr> other than that, it's nice to see progress + < braunr> although again, it would be better with some reports along + < braunr> i won't be present at the meeting tomorrow unfortunately, but you + should use those to report the status of your work + < mcsim> braunr: You've said that I have to tweak gc process. Did you mean + to call mem_gc() when physical memory ends instead of calling it every x + seconds? Or something else? + < braunr> there are multiple topics, alhtough only one that really matters + < braunr> study how zone_gc was called + < braunr> reclaiming memory should happen when there is pressure on the VM + subsystem + < braunr> but it shouldn't happen too ofte, otherwise there is trashing + < braunr> and your caches become mostly useless + < braunr> the original slab allocator uses a 15-second period after a + reclaim during which reclaiming has no effect + < braunr> this allows having a somehow stable working set for this duration + < braunr> the linux slab allocator uses 5 seconds, but has a more + complicated reclaiming mechanism + < braunr> it releases memory gradually, and from reclaimable caches only + (dentry for example) + < braunr> for x15 i intend to implement the original 15 second interval and + then perform full reclaims + < mcsim> In zalloc mem_gc is called by vm_pageout_scan, but not often than + once a second. + < mcsim> In balloc I've changed interval to once in 15 seconds. + < braunr> don't use the code as it is + < braunr> the version you've based your work on was meant for userspace + < braunr> where there isn't memory pressure + < braunr> so a timer is used to trigger reclaims at regular intervals + < braunr> it's different in a kernel + < braunr> mcsim: where did you see vm_pageout_scan call the zone gc once a + second ? + < mcsim> vm_pageout_scan calls consider_zone_gc and consider_zone_gc checks + if second is passed. + < braunr> where ? + < mcsim> Than zone_gc can be called. + < braunr> ah ok, it's in zaclloc.c then + < braunr> zalloc.c + < braunr> yes this function is fine + < mcsim> so old gc didn't consider vm pressure. Or I missed something. + < braunr> it did + < mcsim> how? + < braunr> well, it's called by the pageout daemon + < braunr> under memory pressure + < braunr> so it's fine + < mcsim> so if mem_gc is called by pageout daemon is it fine? + < braunr> it must be changed to do something similar to what + consider_zone_gc does + < mcsim> It does. mem_gc does the same work as consider_zone_gc and + zone_gc. + < braunr> good + < mcsim> so gc process is fine? + < braunr> should be + < braunr> i see mem.c only includes mem.h, which then includes other + headers + < braunr> don't do that + < braunr> always include all the headers you need where you need them + < braunr> if you need avltree.h in both mem.c and mem.h, include it in both + files + < braunr> and by the way, i recommend you use the red black tree instead of + the avl type + < braunr> (it's the same interface so it shouldn't take long) + < mcsim> As to report. If you won't be present at the meeting, I can tell + you what I have to do now. + < braunr> sure + < braunr> in addition, use GPLv2 as the license, teh BSD one is meant for + the userspace version only + < braunr> GPLv2+ actually + < braunr> hm you don't need list.c + < braunr> it would only add dead code + < braunr> "Zone for dynamical allocator", don't mix terms + < braunr> this comment refers to a vm_map, so call it a map + < mcsim> 1. Change constructor for kentry_alloc_cache. + < mcsim> 2. Make measurements. + < mcsim> + + < mcsim> 3. Use simple_lock_data_t + < mcsim> 4. Replace license + < braunr> kentry_alloc_cache <= what is that ? + < braunr> cache for kernel map entries in vm_map ? + < braunr> the comment for mem_cpu_pool_get doesn't apply in gnumach, as + there is no kernel preemption + < braunr> "Don't attempt mem GC more frequently than hz/MEM_GC_INTERVAL + times a second. + < braunr> " + < mcsim> sorry. I meant vm_map_kentry_cache + < braunr> hm nothing actually about this comment + < braunr> mcsim: ok + < braunr> yes kernel map entries need special handling + < braunr> i don't know how it's done in gnumach though + < braunr> static preallocation ? + < mcsim> yes + < braunr> that's ugly :p + < mcsim> but it uses dynamic allocation further even for vm_map kernel + entries + < braunr> although such bootstrapping issues are generally difficult to + solve elegantly + < braunr> ah + < mcsim> now I use only static allocation, but I'll add dynamic allocation + too + < braunr> when you have time, mind the coding style (convert everything to + gnumach style, which mostly implies using tabs instead of 4-spaces + indentation) + < braunr> when you'll work on dynamic allocation for the kernel map + entries, you may want to review how it's done in x15 + < braunr> the mem_source type was originally intended for that purpose, but + has slightly changed once the allocator was adapted to work in my kernel + < mcsim> ok + < braunr> vm_map_kentry_zone is the only zone created with ZONE_FIXED + < braunr> and it is zcram()'ed immediately after + < braunr> so you can consider it a statically allocated zone + < braunr> in x15 i use another strategy: there is a special kernel submap + named kentry_map which contains only one map entry (statically allocated) + < braunr> this map is the backend (mem_source) for the kentry_cache + < braunr> the kentry_cache is created with a special flag that tells it + memory can't be reclaimed + < braunr> when the cache needs to grow, the single map entry is extended to + cover the allocated memory + < braunr> it's similar to the way pmap_growkernel() works for kernel page + table pages + < braunr> (and is actually based on that idea) + < braunr> it's a compromise between full static and dynamic allocation + types + < braunr> the advantage is that the allocator code can be used (so there is + no need for a special allocator like in netbsd) + < braunr> the drawback is that some resources can never be returned to + their source (and under peaks, the amount of unfreeable resources could + become large, but this is unexpected) + < braunr> mcsim: for now you shouldn't waste your time with this + < braunr> i see the number of kernel map entries is fixed at 256 + < braunr> and i've never seen the kernel use more than around 30 entries + < mcsim> Do you think that I have to left this problem to the end? + < braunr> yes + + +# IRC, freenode, #hurd, 2011-08-11 + + < mcsim> braunr: Hello. Can you give me an advice how can I make + measurements better? + < braunr> mcsim: what kind of measurements + < mcsim> braunr: How much is your allocator better than zalloc. + < braunr> slightly :p + < braunr> that's why i never took the time to put it in gnumach + < mcsim> braunr: Just I thought that there are some rules or + recommendations of such measurements. Or I can do them any way I want? + < braunr> mcsim: i don't know + < braunr> mcsim: benchmarking is an art of its own, and i don't even know + how to use the bits of profiling code available in gnumach (if it still + works) + < antrik> mcsim: hm... are you saying you already have a running system + with slab allocator?... :-) + < braunr> mcsim: the main advantage i can see is the removal of many + arbitrary hard limits + < mcsim> antrik: yes + < antrik> \o/ + < antrik> nice work! + < braunr> :) + < braunr> the cpu layer should also help a bit, but it's hard to measure + < braunr> i guess it could be seen on the ipc path for very small buffers + < mcsim> antrik: Thanks. But I still have to 1. Change constructor for + kentry_alloc_cache. and 2. Make measurements. + < braunr> and polish the whole thing :p + < antrik> mcsim: I'm not sure this can be measured... the performance + differente in any real live usage is probably just a few percent at most + -- it's hard to construct a benchmark giving enough precision so it's not + drowned in noise... + < antrik> perhaps it conserves some memory -- but that too would be hard to + measure I fear + < braunr> yes + < braunr> there *should* be better allocation times, less fragmentation, + better accounting ... :) + < braunr> and no arbitrary limits ! + < antrik> :-) + < braunr> oh, and the self debugging features can be nice too + < mcsim> But I need to prove that my work wasn't useless + < braunr> well it wasn't, but that's hard to measure + < braunr> it's easy to prove though, since there are additional features + that weren't present in the zone allocator + < mcsim> Ok. If there are some profiling features in gnumach can you give + me a link with their description? + < braunr> mcsim: sorry, no + < braunr> mcsim: you could still write the basic loop test, which counts + the number of allocations performed in a fixed time interval + < braunr> but as it doesn't match many real life patterns, it won't be very + useful + < braunr> and i'm afraid that if you consider real life patterns, you'll + see how negligeable the improvement can be compared to other operations + such as memory copies or I/O (ouch) + < mcsim> Do network drivers use this allocator? + < mcsim> ok. I'll scrape up some test and than I'll report results. + + +# IRC, freenode, #hurd, 2011-08-26 + + < mcsim> hello. Are there any analogs of copy_to_user and copy_from_user in + linux for gnumach? + < mcsim> Or how can I determine memory map if I know address? I need this + for vm_map_copyin + < guillem> mcsim: vm_map_lookup_entry? + < mcsim> guillem: but I need to transmit map to this function and it will + return an entry which contains specified address. + < mcsim> And I don't know what map have I transmit. + < mcsim> I need to transfer static array from kernel to user. What map + contains static data? + < antrik> mcsim: Mach doesn't have copy_{from,to}_user -- instead, large + chunks of data are transferred as out-of-line data in IPC messages + (i.e. using VM magic) + < mcsim> antrik: can you give me an example? I just found using + vm_map_copyin in host_zone_info. + < antrik> no idea what vm_map_copyin is to be honest... + + +# IRC, freenode, #hurd, 2011-08-27 + + < braunr> mcsim: the primitives are named copyin/copyout, and they are used + for messages with inline data + < braunr> or copyinmsg/copyoutmsg + < braunr> vm_map_copyin/out should be used for chunks larger than a page + (or roughly a page) + < braunr> also, when writing to a task space, see which is better suited: + vm_map_copyout or vm_map_copy_overwrite + < mcsim> braunr: and what will be src_map for vm_map_copyin/out? + < braunr> the caller map + < braunr> which you can get with current_map() iirc + < mcsim> braunr: thank you + < braunr> be careful not to leak anything in the transferred buffers + < braunr> memset() to 0 if in doubt + < mcsim> braunr:ok + < braunr> antrik: vm_map_copyin() is roughly vm_read() + < antrik> braunr: what is it used for? + < braunr> antrik: 01:11 < antrik> mcsim: Mach doesn't have + copy_{from,to}_user -- instead, large chunks of data are transferred as + out-of-line data in IPC messages (i.e. using VM magic) + < braunr> antrik: that "VM magic" is partly implemented using vm_map_copy* + functions + < antrik> braunr: oh, you mean it doesn't actually copy data, but only page + table entries? if so, that's *not* really comparable to + copy_{from,to}_user()... + + +# IRC, freenode, #hurd, 2011-08-28 + + < braunr> antrik: the equivalent of copy_{from,to}_user are + copy{in,out}{,msg} + < braunr> antrik: but when the data size is about a page or more, it's + better not to copy, of course + < antrik> braunr: it's actually not clear at all that it's really better to + do VM magic than to copy... + + +# IRC, freenode, #hurd, 2011-08-29 + + < braunr> antrik: at least, that used to be the general idea, and with a + simpler VM i suspect it's still true + < braunr> mcsim: did you progress on your host_zone_info replacement ? + < braunr> mcsim: i think you should stick to what the original + implementation did + < braunr> which is making an inline copy if caller provided enough space, + using kmem_alloc_pageable otherwise + < braunr> specify ipc_kernel_map if using kmem_alloc_pageable + < mcsim> braunr: yes. And it works. But I use kmem_alloc, not pageable. Is + it worse? + < mcsim> braunr: host_zone_info replacement is pushed to savannah + repository. + < braunr> mcsim: i'll have a look + < mcsim> braunr: I've pushed one more commit just now, which has attitude + to host_zone_info. + < braunr> mem_alloc_early_init should be renamed mem_bootstrap + < mcsim> ok + < braunr> mcsim: i don't understand your call to kmem_free + < mcsim> braunr: It shouldn't be there? + < braunr> why should it be there ? + < braunr> you're freeing what the copy object references + < braunr> it's strange that it even works + < braunr> also, you shouldn't pass infop directly as the copy object + < braunr> i guess you get a warning for that + < braunr> do what the original code does: use an intermediate copy object + and a cast + < mcsim> ok + < braunr> another error (without consequence but still, you should mind it) + < braunr> simple_lock(&mem_cache_list_lock); + < braunr> [...] + < braunr> kr = kmem_alloc(ipc_kernel_map, &info, info_size); + < braunr> you can't hold simple locks while allocating memory + < braunr> read how the original implementation works around this + < mcsim> ok + < braunr> i guess host_zone_info assumes the zone list doesn't change much + while unlocked + < braunr> or that's it's rather unimportant since it's for debugging + < braunr> a strict snapshot isn't required + < braunr> list_for_each_entry(&mem_cache_list, cache, node) max_caches++; + < braunr> you should really use two separate lines for readability + < braunr> also, instead of counting each time, you could just maintain a + global counter + < braunr> mcsim: use strncpy instead of strcpy for the cache names + < braunr> not to avoid overflow but rather to clear the unused bytes at the + end of the buffer + < braunr> mcsim: about kmem_alloc vs kmem_alloc_pageable, it's a minor + issue + < braunr> you're handing off debugging data to a userspace application + < braunr> a rather dull reporting tool in most cases, which doesn't require + wired down memory + < braunr> so in order to better use available memory, pageable memory + should be used + < braunr> in the future i guess it could become a not-so-minor issue though + < mcsim> ok. I'll fix it + < braunr> mcsim: have you tried to run the kernel with MC_VERIFY always on + ? + < braunr> MEM_CF_VERIFY actually + < mcsim1> yes. + < braunr> oh + < braunr> nothing wrong + < braunr> ? + < mcsim1> it is always set + < braunr> ok + < braunr> ah, you set it in macros.h .. + < braunr> don't + < braunr> put it in mem.c if you want, or better, make it a compile-time + option + < braunr> macros.h is a tiny macro library, it shouldn't define such + unrelated options + < mcsim1> ok. + < braunr> mcsim1: did you try fault injection to make sure the checking + code actually works and how it behaves when an error occurs ? + < mcsim1> I think that when I finish I'll merge files cpu.h and macros.h + with mem.c + < braunr> yes that would simplify things + < mcsim1> Yes. When I confused with types mem_buf_fill worked wrong and + panic occurred. + < braunr> very good + < braunr> have you progressed concerning the measurements you wanted to do + ? + < mcsim1> not much. + < braunr> ok + < mcsim1> I think they will be ready in a few days. + < antrik> what measurements are these? + < mcsim1> braunr: What maximal size for static data and stack in kernel? + < braunr> what do you mean ? + < braunr> kernel stacks are one page if i'm right + < braunr> static data (rodata+data+bss) are limited by grub bugs only :) + < mcsim1> braunr: probably they are present, because when I created too big + array I couldn't boot kernel + < braunr> local variable or static ? + < mcsim1> static + < braunr> how large ? + < mcsim1> 4Mb + < braunr> hm + < braunr> it's not a grub bug then + < braunr> i was able to embed as much as 32 MiB in x15 while doing this + kind of tests + < braunr> I guess it's the gnu mach boot code which only preallocates one + page for the initial kernel mapping + < braunr> one PTP (page table page) maps 4 MiB + < braunr> (x15 does this completely dynamically, unlike mach or even + current BSDs) + < mcsim1> antrik: First I want to measure time of each cache + creation/allocation/deallocation and then compile kernel. + < braunr> cache creation is irrelevant + < braunr> because of the cpu pools in the new allocator, you should test at + least two different allocation patterns + < braunr> one with quick allocs/frees + < braunr> the other with large numbers of allocs then their matching frees + < braunr> (larger being at least 100) + < braunr> i'd say the cpu pool layer is the real advantage over the + previous zone allocator + < braunr> (from a performance perspective) + < mcsim1> But there is only one cpu + < braunr> it doesn't matter + < braunr> it's stil a very effective cache + < braunr> in addition to reducing contention + < braunr> compare mem_cpu_pool_pop() against mem_cache_alloc_from_slab() + < braunr> mcsim1: work is needed to polish the whole thing, but getting it + actually working is a nice achievement for someone new on the project + < braunr> i hope it helped you learn about memory allocation, virtual + memory, gnu mach and the hurd in general :) + < antrik> indeed :-) diff --git a/open_issues/hurd_101.mdwn b/open_issues/hurd_101.mdwn new file mode 100644 index 00000000..5c7031c9 --- /dev/null +++ b/open_issues/hurd_101.mdwn @@ -0,0 +1,38 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +(See Wikipedia page for the meaning of [[!wikipedia "101_(term)"]].) + +Not the first time that something like this is proposed... + +IRC, freenode, #hurd, 2011-07-25 + + [failed GNU/Hurd project] + < antrik> gnu_srs1: I wouldn't say he was on track. just one of the many + many people who insist on picking a hard task; realizing that indeed it's + hard; and going into hiding + < antrik> we see that happen every couple of months + < cluck> maybe we need a "hurd 101" + < cluck> getting a teacher and setting up a regularly held "class" for hurd + noobs + < Tekk_> cluck: what would that include? + < cluck> explaining core concepts, giving out "homework" (small tasks), etc + < cluck> that way "the big guys" could focus on the hard stuff and have an + army of code monkeys at their disposal to write speced stuff + < cluck> (then again this idea would heavily depend on available "teachers" + and "students", which, going by gsoc numbers, may not be all that + helpful) + < Tekk_> cluck: gsoc isn't an accurate indicator + < Tekk_> cluck: I'm not allowed to participate in gsoc but I'd join :P + < antrik> cluck: we don't need code monkeys... we need hackers + < Tekk_`> antrik: code monkeys involve into hackers + < Tekk_`> under the right conditions + < cluck> antrik: jokes aside some sort of triage system/training ground for + newcomers could be helpful diff --git a/open_issues/libpthread_dlopen.mdwn b/open_issues/libpthread_dlopen.mdwn index 0d3628ec..fb665c67 100644 --- a/open_issues/libpthread_dlopen.mdwn +++ b/open_issues/libpthread_dlopen.mdwn @@ -40,8 +40,36 @@ IRC, OFTC, #debian-hurd, 2011-07-21. The fix thus being: link the main application with -lpthread. -The same symptom appears in an odd case, for instance: +IRC, freenode, #hurd, 2011-08-17 + + < youpi> i.e. openjade apparently dlopen()s modules which use pthreads, but + openjade itself is not liked against libpthread + < youpi> which means unexpectedly loading pthreads on the fly, which is + not implemented + < youpi> (and hard to implement of course) + < youpi> gnu_srs: so simply tell openjade people to link it with -lpthread + < gnu_srs> Shuoldn't missing linking with pthread create an error when + building openjade then? + < youpi> no + < youpi> because it's just a module which needs pthread + < youpi> and that module _is_ linked with -lpthread + < youpi> and dlopen() loads libpthreads too due to that + < youpi> but that's unexpected, for the libpthread initialization stuff + < youpi> (and too late to fix initlaization) + < gnu_srs> How come that other OSes build opensp w/o problems? + < youpi> because there are stubs in the libc + < gnu_srs> Sorry for the delay: What hinders stubs to be present also in + the Hurd libc parts too, to cope with this problem? + < youpi> doing it + < youpi> which is hard because you need libpthread bits inside the libc + < youpi> making it simpler would need building libpthread at the same time + as libc + +[[packaging_libpthread]] +--- + +The same symptom appears in an odd case, for instance: buildd@hurd:~$ ldd /usr/bin/openjade libthreads.so.0.3 => /lib/libthreads.so.0.3 (0x0103d000) diff --git a/open_issues/mach_tasks_memory_usage.mdwn b/open_issues/mach_tasks_memory_usage.mdwn index 88e3afb8..9abb7639 100644 --- a/open_issues/mach_tasks_memory_usage.mdwn +++ b/open_issues/mach_tasks_memory_usage.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation]] -IRC, #hurd, 2011-01-06. +IRC, freenode, #hurd, 2011-01-06 hm, odd... vmstat tells me that ~500 MiB of RAM are in use; but the sum of all RSS is <300 MiB... what's the rest? @@ -98,3 +98,50 @@ IRC, #hurd, 2011-01-06. braunr: yeah for bootstrapping issues, makes sense it may also depends on the pic/pie options used when building libraries + + +IRC, freenode, #hurd, 2011-07-24 + + < braunr> the panic is probably due to memory shortage + < braunr> so as antrik suggested, use more swap + < antrik> gg0: you could run "vmstat 1" in another terminal to watch memory + usage + < antrik> that way we will know for sure whether it's related + < braunr> antrik: it's trickier than that + < braunr> it depends if the zones used are pageable + < antrik> braunr: well, if it's a zone map exhaustion, then the swap size + won't change anything?... + < braunr> antrik: in this case no, but if the zone is pageable and the + pager (backing anonymous memory) refuses to create memory because it + estimates it's full (all swap space is reserved), it will fail to + < braunr> too + < braunr> but i don't think there are much pageable zones in the kernel + < antrik> yes, but in that case we can see the exhaustion in vmstat :-) + < braunr> many* + < braunr> i'm not sure + < braunr> reserved swap space doesn't mean it's used + < braunr> that's one of the major changes in freebsd 4 or 5 i was + mentioning + < antrik> if it's reserved, it wouldn't show up as "free", would it?... + < braunr> (btw, it's also what makes anonymous memory merging so hard) + < braunr> yes it would + < braunr> well, it could, i'm not sure + < braunr> anonymous memory is considered as a file + < braunr> one big file filled with zeroes, which is the swap partition + < braunr> when you allocate pageable anonymous memory, a part of this + "file" is reserved + < braunr> but i don't know if the reported number if the reserved + (allocated) space, or used (actually containing data) + < braunr> is* + < braunr> i also suspect wired allocations can fail because of a full swap + (because the kernel is unable to make free pages) + < braunr> in this case vmstat will show it + < antrik> what does it matter whether there is data there or not? if it's + reserved, it's not free. if it behaves differently, I'd consider that a + serious bug + < braunr> maybe the original developers intended to monitor its actual + usage + < braunr> antrik: i've just checked how the free count gets updated, and it + looks like it is on both seqnos_memory_object_data_initialize and + seqnos_memory_object_data_write + < braunr> antrik: so i guess reserved memory is accounted for diff --git a/open_issues/mmap_crash_etc.mdwn b/open_issues/mmap_crash_etc.mdwn new file mode 100644 index 00000000..4946a5a0 --- /dev/null +++ b/open_issues/mmap_crash_etc.mdwn @@ -0,0 +1,95 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +Several issues here: + + * [[!tag open_issue_glibc open_issue_gnumach]] Even invalid `mmap` shoudn't + crash the process. + + * [[!tag open_issue_documentation]] The memory layout example should be + documented. + + * [[!tag open_issue_gnumach]] New `vm_map` allocation strategy may be + desirable; see also [[placement_of_virtual_memory_regions]]. + + * [[!tag open_issue_glibc]] *task X deallocating an invalid port Y, most + probably a bug*. + +IRC, freenode, #hurd, 2011-08-11 + + < zyg> oh, mmap sigsegvs, strange. + < braunr> hwo do you see that ? + < zyg> braunr: I'll try to paste a minimal case + < braunr> zyg: make sure you have a sane memory setup + < braunr> 512 RAM / 1G swap seems good + < braunr> have more swap than RAM + < zyg> I have those. Still it shouldn't sigsegv. + < braunr> gnumach is picky about that + < braunr> and yes, the hurd shouldn't have bugs + < zyg> braunr: ready to crash? #include #include int + main (int argc, char **argv) { mmap(0x10000, 0x8000, PROT_READ, MAP_ANON + | MAP_FIXED, -1, 0); return 0; } + < braunr> a fixed mapping at such an address is likely to fail, yes + < braunr> but a crash, hm + < zyg> why should it fail? + < braunr> because the hurd doesn't have a common text data bss heap stack + layout + < braunr> e.g. there are mappings below text, as show by vminfo : + < braunr> $ vminfo $$ + < braunr> 0[0x1000] (prot=0) + < braunr> 0x1000[0x21000] (prot=RX, max_prot=RWX, mem_obj=105) + < braunr> 0x22000[0x1000] (prot=R, max_prot=RWX, mem_obj=105) + < braunr> 0x23000[0x1000] (prot=RW, max_prot=RWX, mem_obj=105) + < braunr> 0x24000[0x1000] (prot=0, max_prot=RWX) + < braunr> 0x25000[0xfff000] (prot=RWX, mem_obj=106) + < braunr> 0x1024000[0x1000] (prot=RWX, mem_obj=107) + < braunr> 0x1025000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108) + < braunr> 0x1026000[0x1000] (prot=RW, max_prot=RWX, mem_obj=108, + offs=0x1000) + < braunr> 0x1027000[0x1000] (prot=RW, max_prot=RWX, mem_obj=109) + < braunr> 0x1028000[0x2000] (prot=RW, max_prot=RWX, mem_obj=110, + offs=0x1000) + < braunr> 0x102a000[0x1000] (prot=RW, max_prot=RWX, mem_obj=111) + < braunr> (sorry for the long paste) + < zyg> oh.. my mmap falls into an occupied range? + < braunr> seems so + < zyg> thanks, that was really useful. + < braunr> MAP_FIXED isn't portable, this is clearly stated in most man + pages + < zyg> yes, implementation specific it says + < braunr> well the behaviour isn't specific, it's well defined, but the + memory layout isn't + < braunr> i personally think vm_map() should be slightly changed to include + a new flag for top-down allocations + < braunr> so that our stack and libraries are at high addresses, below the + kernel + < braunr> zyg: what kind of error do you get ? i don't get sigsegv + < zyg> I get both sigsegv and sigill depending on addr + < braunr> ok + < braunr> i get sigill with your example + < braunr> the error is the same (wrong memory access) but the behaviour + changes because of the special memory configuration + < zyg> yes.. I guess the usecase is too uncommon. Else mmap would have an + guard + < braunr> some accesses cause invalid page faults (which are sent as + segmentation faults) while other cause general protection faults (which + are sent as illegal instructions) + < braunr> (this is quite weird since the GP fault is likely because the + access targets something out of the data or code segment eh) + < zyg> braunr: that's very os-specific. Do you mean hurd behaves that way? + < braunr> gnumach + < braunr> on i386 + < braunr> the segmant configuration isn't completely flat + < braunr> segment* + < braunr> hm nice + < braunr> your small program triggers the "task X deallocating an invalid + port Y, most probably a bug." message + < zyg> where do you see that? + < braunr> on the mach console diff --git a/open_issues/multiprocessing.mdwn b/open_issues/multiprocessing.mdwn index 224c0826..562ccd83 100644 --- a/open_issues/multiprocessing.mdwn +++ b/open_issues/multiprocessing.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -8,7 +8,7 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] -[[!tag open_issue_hurd]] +[[!tag open_issue_documentation open_issue_hurd]] We would expect that fine-grained, compartmentalized systems, that is, microkernel-based multi-server systems in particular, would be ideal candidates @@ -16,7 +16,7 @@ for applying multiprocessing. That is, however, only true from a first and inexperienced point of view: there are many difficulties. -IRC, #hurd, August / September 2010 +IRC, freenode, #hurd, August / September 2010 silver_hook: because multi-server systems depend on inter-process communication, and inter-process communication is many times more @@ -31,6 +31,37 @@ IRC, #hurd, August / September 2010 serious research challenges +IRC, freenode, #hurd, 2011-07-26 + + < braunr> 12:03 < CTKArcher> and does the hurd take more advantages in a + multicore architecture than linux ? + < braunr> CTKArcher: short answer: no + < CTKArcher> it's easier to imagine one server pro core than the linux + kernel divided to be executed on multiple cores + < braunr> CTKArcher: this approach is less efficient + < braunr> CTKArcher: threads carry state, both explicit and implicit (like + cache data) + < braunr> CTKArcher: switching to another core means resetting and + refetching this state + < braunr> it's expensive and there is no gain obtained by doing this + < braunr> thread migration (having a thread from a client also run in + servers when making synchronous RPC, even handling its own page faults) + was implemented in mach4 and is imo a very good thing we should have + < braunr> CTKArcher: and concerning linux, it's actually very scalable + < braunr> it's already like if all client threads run in servers (the + kernel is the servers there) + < braunr> rcu is used a lot + < braunr> thread migration already takes into account smt, cores, and numa + < braunr> it's hard to do something better + < braunr> (here, thread migration means being dispatched on another cpu) + < braunr> some systems like dragonflybsd go as far as to pin threads on one + processor for their entire lifetime + < braunr> in order to have rcu-like locking almost everywhere + < braunr> (you could argue it's less efficient since in the worst case + everything runs on the same cpu, but it's very unlikely, and in practice + most patterns are well balanced) + + debian-hurd list On Thu, Jan 02, 2003 at 05:40:00PM -0800, Thomas Bushnell, BSG wrote: diff --git a/open_issues/packaging_libpthread.mdwn b/open_issues/packaging_libpthread.mdwn index 7594ae76..fa3d4312 100644 --- a/open_issues/packaging_libpthread.mdwn +++ b/open_issues/packaging_libpthread.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -15,6 +15,9 @@ IRC, #hurd, 2010-07-31 My idea was to have a separate libpthread package. What do you think about that? in the long term, that can't work with glibc because of the thread stub stuff + +[[libpthread_dlopen]], for example. + it's not really possible to keep synchronized because you have to decide which package you unpack first (when upgrading) diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index eb9f3f8a..54f3ce39 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -26,3 +26,7 @@ severe performance degradation. For example, in this [[`fork` system call|/glibc/fork]]'s case. [[Unit_testing]] can be used for tracking performance regressions. + +--- + + * [[Degradation]] diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn new file mode 100644 index 00000000..5db82e31 --- /dev/null +++ b/open_issues/performance/degradation.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Degradation of GNU/Hurd ``system performance''"]] + +Email, *id:"87mxg2ahh8.fsf@kepler.schwinge.homeip.net"* (bug-hurd, 2011-07-25, +Thomas Schwinge) + +> Building a certain GCC configuration on a freshly booted system: 11 h. +> Remove build tree, build it again (2nd): 12 h 50 min. Huh. Remove build +> tree, reboot, build it again (1st): back to 11 h. Remove build tree, build +> it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. + +IRC, freenode, #hurd, 2011-07-23 + + < antrik> tschwinge: yes, the system definitely gets slower with + time. after running for a couple of weeks, it needs at least twice as + long to open a new shell for example + < antrik> I don't know whether this is only related to swap usage, or there + are some serious fragmentation issues + < braunr> antrik: both could be induced by fragmentation diff --git a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn index 79c2300f..359d5fee 100644 --- a/open_issues/performance/io_system/binutils_ld_64ksec.mdwn +++ b/open_issues/performance/io_system/binutils_ld_64ksec.mdwn @@ -33,3 +33,18 @@ the testee shows that (primarily) an ever-repeating series of `io_seek` and `io_read` is being processed. Running the testee on GNU/Linux with strace shows the equivalent thing (`_llseek`, `read`) -- but Linux' I/O system isn't as slow as the Hurd's. + +--- + +IRC, freenode, #hurd, 2011-09-01: + + hum, f951 does myriads of 71->io_seek_request (32768 0) = 0 32768 + no wonder it's slow + unfortunately that's also what it does on linux, the system call is + just less costly + apparently gfortran calls io_seek for, like, every token of the + sourced file + (fgetpos actually, but that's the same) + and it is indeed about 10 times slower under Xen for some reason + +[[!tag open_issue_xen]] diff --git a/open_issues/performance/microkernel_multi-server.mdwn b/open_issues/performance/microkernel_multi-server.mdwn new file mode 100644 index 00000000..111d2b88 --- /dev/null +++ b/open_issues/performance/microkernel_multi-server.mdwn @@ -0,0 +1,47 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + +Performance issues due to the microkernel/multi-server system architecture? + +IRC, freenode, #hurd, 2011-07-26 + + < CTKArcher> I read that, because of its microkernel+servers design, the + hurd was slower than a monolithic kernel, is that confirmed ? + < youpi> the hurd is currently slower than current monolithic kernels, but + it's not due to the microkernel + servers design + < youpi> the microkernel+servers design makes the system call path longer + < youpi> but you're bound by disk and network speed + < youpi> so the extra overhead will not hurt so much + < youpi> except dumb applications keeping doing system calls all the time + of course, but they are usually considered bogus + < braunr> there may be some patterns (like applications using pipes + extensively, e.g. git-svn) which may suffer from the design, but still in + an acceptable range + < CTKArcher> so, you are saying that disk and network are more slowing the + system than the longer system call path and because of that, it wont + really matter ? + < youpi> braunr: they should sitll be fixed because they'll suffer (even if + less) on monolithic kernels + < youpi> CTKArcher: yes + < braunr> yes + < CTKArcher> mmh + < youpi> CTKArcher: you might want to listen to AST's talk at fosdem 10 + iirc, about minix + < youpi> they even go as far as using an IPC for each low-level in/out + < youpi> for security + < braunr> this has been expected for a long time + < braunr> which is what motivated research in microkernels + < CTKArcher> I've already downloaded the video :) + < youpi> and it has been more and more true with faster and faster cpus + < braunr> but in 95, processors weren't that fast compared to other + components as they are now + < youpi> while disk/mem haven't evovled so fast diff --git a/open_issues/proc_server_proc_exception_raise.mdwn b/open_issues/proc_server_proc_exception_raise.mdwn new file mode 100644 index 00000000..1d0e92a3 --- /dev/null +++ b/open_issues/proc_server_proc_exception_raise.mdwn @@ -0,0 +1,37 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2011-08-11 + + < youpi> in which error cases a reply port will actually have been consumed + by mach_msg ? + < youpi> it seems at least MACH_SEND_NOTIFY_IN_PROGRESS do? + < braunr> + http://www.gnu.org/software/hurd/gnumach-doc/Message-Send.html#Message-Send + < braunr> "These return codes imply that the message was returned to the + caller with a pseudo-receive operation: " + < braunr> isn't it what you're looking for ? + < youpi> well, it's hard to tell from the name + < youpi> I don't know what "pseudo-receiv operation" means + < braunr> it's described below + < youpi> ew + < braunr> it looks close enough to a normal receive to assume it consumes + the reply port + < youpi> so it's even more complex than what I thought + < youpi> well, no, it returns the right + < youpi> actually the error I'm getting is MACH_RCV_INVALID_NAME + < youpi> which I guess means the sending part succeeded + < youpi> the case at stake is proc/mgt.c: S_proc_exception_raise() + < youpi> when the proc_exception_raise() forward fails + < youpi> currently we always return 0, but if proc_exception_raise() + actually managed to send the message, the reply port was consumed and + MIG_NO_REPLY should be returned instead diff --git a/open_issues/resource_management_problems.mdwn b/open_issues/resource_management_problems.mdwn index 760c7d66..1558bebb 100644 --- a/open_issues/resource_management_problems.mdwn +++ b/open_issues/resource_management_problems.mdwn @@ -61,7 +61,22 @@ This is, of course, non-trivial to implement, and also requires changing the SPLICE_F_GIFT flag](http://www.kernel.org/doc/man-pages/online/pages/man2/vmsplice.2.html#DESCRIPTION).) +IRC, freenode, #hurd, 2011-07-31 + + < braunr> one of the biggest problems on the hurd is that, when a client + makes a call, kernel (and other) resources are allocated on behalf of the + server performaing the requested action + < braunr> performing* + < braunr> this makes implementing scheduling and limits difficult + < CTKArcher> And could changing the kernel change anything to that ? + < braunr> yes but you'd probably need to change its interface as well + < braunr> iirc, the critique describes resource containers + < braunr> but no work has been done on the current hurd (hence the hurdng + attempts) + # Further Examples + * [[IO_accounting]] + * [[configure max command line length]] diff --git a/open_issues/resource_management_problems/io_accounting.mdwn b/open_issues/resource_management_problems/io_accounting.mdwn new file mode 100644 index 00000000..113b965a --- /dev/null +++ b/open_issues/resource_management_problems/io_accounting.mdwn @@ -0,0 +1,49 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, freenode, #hurd, 2011-07-22 + + an interesting question i've had in mind for a few weeks now is + I/O accounting + what *is* I/O on a microkernel based system ? + can any cross address space transfer be classified as I/O ? + +IRC, freenode, #hurd, 2011-07-29 + + < braunr> how does the hurd account I/O ? + < youpi> I don't think it does + < youpi> not an easy task, actually + < youpi> since gnumach has no idea about it + < braunr> yes + < braunr> another centralization issue + < braunr> does network access count as I/O on linux ? + < youpi> no + < braunr> not even nfs ? + < youpi> else you'd get 100% for servers :) + < braunr> right + < youpi> nfs goes through vfs first + < braunr> i'll rephrase my question + < youpi> I'd need to check but I believe it can check nfs + < braunr> does I/O accounting occur at the vfs level or block layer ? + < youpi> I don't know, but I beleive vfs + < youpi> (at least that's how I'd do it) + < braunr> i don't have any more nfs box to test that :/ + < braunr> personally i'd do it at the block layer :) + < youpi> well, both + < youpi> so e2fsck can show up too + < braunr> yes + < youpi> it's just a matter of ref counting + < youpi> apparently nfs doesn't account + < youpi> find . -printf "" doesn't show up in waitio + < braunr> good + < youpi> well, depends on the point of view + < youpi> as a user, you'd like to know whether your processes are stuck on + i/o (be it disk or net) + < braunr> this implies clearly defining what io is diff --git a/open_issues/sa_siginfo_sa_sigaction.mdwn b/open_issues/sa_siginfo_sa_sigaction.mdwn index d6199b6a..3b8edff7 100644 --- a/open_issues/sa_siginfo_sa_sigaction.mdwn +++ b/open_issues/sa_siginfo_sa_sigaction.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -45,3 +45,50 @@ IRC, #hurd, August / September 2010: (i.e. replace with 0 in your example) ok when SA_SIGINFO becomes available, it'll just be used + +IRC, freenode, #hurd, 2011-08-20: + + < youpi> erf, tcpwrappers will need si_pid + < jkoenig> I could implement it not too far away in the future, we just + need a version of msg_sig_post() with a siginfo argument or something. + < youpi> I can also see a lot of packages using SA_SIGINFO for no reason... + < youpi> (probably copy/pasty code) + < youpi> sa.sa_flags = SA_SIGINFO; + < youpi> sa.sa_handler = parse_config; + < youpi> void parse_config(int) + < youpi> yay + < youpi> if(siginf->si_signo == SIGXCPU) + < youpi> fprintf(stderr, "Exceeded CPU usage.\n"); + < youpi> ... + < youpi> jkoenig: actually most package don't actually use the SA_SIGINFO + they request... + < youpi> jkoenig: si_pid should get us almost all actually used coverage + < youpi> I've seen only one example using si_errno + < jkoenig> ok + < youpi> oh, it's actually supported by your patch + < youpi> (errno) + < jkoenig> but I guess since implementing si_pid will require a new RPC, we + might as well plan for the rest + < youpi> jkoenig: indeed + < jkoenig> youpi, hmm I doubt it's properly filled in in all circumstances? + < youpi> ok, well, we'll see + < pinotree> jkoenig: if it can be of help, boost::unit_test queries various + fields of siginfo_t depending on the signal + < pinotree> jkoenig: also, pulseaudio uses siginfo_t for remapping faulting + memory on SIGBUS + < jkoenig> pinotree, oh ok good to know + < pinotree> *faulty + < youpi> jkoenig: well, I guess you had checked that the si_addr field is + correct in a few simple testcase :) + < jkoenig> hmm I think so, yes + < jkoenig> I ran like, "* (char *) 0x12345678;" or something IIRC + < youpi> ok + < jkoenig> I seem to remember mach generated SIGBUS instead of SIGSEGV + depending on the upper bit, or something (I can't quite remember) + < jkoenig> but when sigsegv was generated si_addr was right. + < pinotree> jkoenig: (see boost/test/impl/execution_monitor.ipp in boost + sources) + < pinotree> maybe you can try the unit tests for boost::unit_tests, if any + :) + < pinotree> (while src/pulsecore/memtrap.c in PA) + * pinotree stops doing MrObvious™ diff --git a/open_issues/sbcl.mdwn b/open_issues/sbcl.mdwn new file mode 100644 index 00000000..4bbf92ef --- /dev/null +++ b/open_issues/sbcl.mdwn @@ -0,0 +1,31 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_porting]] + +IRC, freenode, #hurd, 2011-08-12 + + < zyg> did the segment registers had any purpose? I see fs is set equal to + others, but on linux fs is 0 (atleast on this x86 box). + < braunr> zyg: it can be used by special applications like wine, yes + < zyg> braunr: thanks.. I'm reading up on linux actually. It seems gs can + be used for TLS, fs in syscall to pass userspace. + < braunr> zyg: why are you interested in that ? + < zyg> a native compiler under linux places assumptions on fs register. So + I'm trying to find out what it should do under gnumach/hurd. + < braunr> what compiler ? + < zyg> braunr: it's sbcl + < braunr> ok + < youpi> zyg: the same, basically + < zyg> ok.. looking at the code, I've remarked where it sets up FS, because + /usr/include/asm/ldt.h:struct user_desc is missing. I must search for the + equiv. + < youpi> zyg: mach/i386/mach_i386.h + < youpi> the descriptor structure diff --git a/open_issues/sendmsg_scm_creds.mdwn b/open_issues/sendmsg_scm_creds.mdwn index 2deec7e8..c613e21c 100644 --- a/open_issues/sendmsg_scm_creds.mdwn +++ b/open_issues/sendmsg_scm_creds.mdwn @@ -90,6 +90,10 @@ IRC, unknown channel, unknown date. yep ok, good :) +/!\ IRC, freenode, #hurd, 2011-08-11 + + < pinotree> (but that patch is lame) + --- See also [[pflocal_socket_credentials_for_local_sockets]] and [[pflocal_reauth]]. diff --git a/open_issues/syslog.mdwn b/open_issues/syslog.mdwn index 778933a7..5fec38b1 100644 --- a/open_issues/syslog.mdwn +++ b/open_issues/syslog.mdwn @@ -1,7 +1,45 @@ IRC, unknwon channel, unknown date. - scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 I see that you intend(ed) to use syslog for logging debug messages. I thought I'd point you to http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no idea if that's still an issue or what went wrong at that time. Perhaps you can have a look? - tschwinge: Thanks for information! Currently I'm logging some debug messages to a simple file, but I'll now check whether the issue you've pointed out is still present. - tschwinge: I am getting absolutely abnormal results: when I call syslog() from a simple C program for the first time, the message goes to the system log. However, any further calls to syslog() do just nothing... I am able to send something to syslog only after reboot (it doesn't help if I restart syslogd). + scolobb: In wiki edit 60accafa79f645ae61b578403f7fc0c11914b725 + I see that you intend(ed) to use syslog for logging debug messages. I + thought I'd point you to + http://lists.gnu.org/archive/html/bug-hurd/2007-02/msg00042.html -- no + idea if that's still an issue or what went wrong at that time. Perhaps + you can have a look? + tschwinge: Thanks for information! Currently I'm logging some + debug messages to a simple file, but I'll now check whether the issue + you've pointed out is still present. + tschwinge: I am getting absolutely abnormal results: when I call + syslog() from a simple C program for the first time, the message goes to + the system log. However, any further calls to syslog() do just + nothing... I am able to send something to syslog only after reboot (it + doesn't help if I restart syslogd). +IRC, freenode, #hurd, 2011-08-08 + + < pinotree> wow, `logger` + a simple C udp server can cause havoc + < pinotree> youpi: ever seen something like + http://paste.debian.net/hidden/72cf4b77/ ? + < pinotree> and then also other servers (like pflocal, pfinet, few more) + start becoming crazy (using 100% cpu) + < youpi> nope + < pinotree> iirc in one of the few tries i got the message "Resource lost." + from the closed ssh connection + < pinotree> i was trying to see why syslog doesn't work, but this basically + surprised me... + < pinotree> oh, i found an apparently working syslog daemon + < pinotree> dsyslog + < gg0> have you tried syslog-ng? IIRC it writes in /var/log/messages by + default. + < pinotree> yeah, it seems to stop receiving messages are few + < pinotree> gg0: are you using syslog-ng? + < gg0> pinotree: I should fire hurd vm up. I seem I kept dirty-patched + busybox syslog, I don't even know if it works, at least it starts + http://bugs.debian.org/636162 + < pinotree> maintainer said "not really" + < gg0> well, if all other syslogs use shm and sems, they won't work too, + right? + < youpi> shm should work with the latest libc + < youpi> what won't is sysv sem + < youpi> (i.e. semget) diff --git a/open_issues/tty_activitiy_vs_disk_io.mdwn b/open_issues/tty_activitiy_vs_disk_io.mdwn new file mode 100644 index 00000000..26382d56 --- /dev/null +++ b/open_issues/tty_activitiy_vs_disk_io.mdwn @@ -0,0 +1,81 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_hurd]] + +IRC, freenode, #hurd, 2011-07-25 + + < youpi> Mmm, typing something on the mach console triggers a write on the + disk + < youpi> because the /dev/console node gets updated + < youpi> I don't really see why + < youpi> (yes, just typing at the bash prompt, not even running something) + < youpi> typing during the sleep command (i.e. mere tty echo) doesn't + trigger it, however + < youpi> running bash's echo does trigger it + < braunr> during sleep, the glibc stream functions handle I/O, while with + bash, its readline takes care of it, right ? + < youpi> /bin/echo too + < youpi> during sleep it's the tty process which handles I/O + < braunr> the write may be due to a write time update on the inode + < braunr> modification* time + < youpi> probably yes, but how so? + < youpi> ext2fs is only supposed to pass the thing to the console + translator + < braunr> not sure + < youpi> actually, ext2fs even isn't supposed to come into play when it's + about typing at the bash prompt + < youpi> once it's opened, isn't the port for /dev/console supposed to be + directly to the translator there? + < braunr> i think so + < youpi> (s/tty/term/ in what I said) + < braunr> well, it's certain + < youpi> so I don't see how ext2fs can be triggered to write an atime or + mtime + < braunr> what does rpctrace say ? + < youpi> io_read_request and io_write_request + < youpi> braunr: it doesn't happen at the login prompt + < youpi> interestingly, atime is always 3-4 secs earlier than ctime & mtime + < youpi> doesn't happen with dash + < braunr> we should implement relatime and experiment with it + < braunr> it shouldn't be hard + < youpi> well, there's noatime already + < youpi> but my point is that this update shouldn't happen + < youpi> and I believe it's the source of the i_file_acl e2fsck warning + < braunr> i wasn't saying that concerning this problem, it was just a + separate idea (noatime is more problematic than relatime) + < braunr> and i agree, it shouldn't happen :) + < youpi> ok, it's set_node_times which gets called + +IRC, freenode, #hurd, 2011-07-27 + + < antrik> BTW, I'm not sure it's still relevant; but the reason accessing + translators such as the console modifies the underlying node is that most + stat information is generally passed through + < antrik> (in some cases it might be unintentional though, simply using the + default implementation from trivfs carelessly...) + < youpi> I know + < youpi> I've seen that in the code + < antrik> OK + < youpi> it is still relevant: I still find it useless to write it on the + disk + < youpi> though w uses it to show idle time over reboot + < braunr> is it useful to keep the information across reboots ? + < youpi> for some value of "useful" for w + < braunr> i wonder what would break if this was entierly kept in memory + < youpi> nothing, probably + < youpi> note that it doesn't overload ext2fs so much, it just adds a write + every ~5s + < youpi> (at worse, i.e. when keeping showing text, for instance) + < braunr> indeed, the behaviour seems the same on linux + < antrik> ah... that explains why the disk doesn't spin down while IRC is + active... always wondered about that :-) + < youpi> that's not very power-saving, yes + < youpi> well, we might want to put /dev on ram someday diff --git a/open_issues/user-space_device_drivers.mdwn b/open_issues/user-space_device_drivers.mdwn index b8061f71..e929f2bf 100644 --- a/open_issues/user-space_device_drivers.mdwn +++ b/open_issues/user-space_device_drivers.mdwn @@ -33,6 +33,16 @@ Also see [[device drivers and IO systems]]. to IRQs. However, at least in GNU Mach, that code (`kern/eventcount.c`) doesn't seem functional at all and isn't integrated properly in the kernel. + * IRC, freenode, #hurd, 2011-07-29 + + < antrik> regarding performance of userspace drivers, there is one + thing that really adds considerable overhead: interrupt + handling. whether this is relevant very much depends on the hardware + in question. when sending many small packets over gigabit ethernet, + it might be noticable; in most other cases it's irrelevant + < youpi> some cards support interrupt coalescin + < youpi> could be supported by DDE too + ## DMA * Security considerations. @@ -52,6 +62,32 @@ Also see [[device drivers and IO systems]]. * [[GNU Mach|microkernel/mach/gnumach]] is said to have a high overhead when doing RPC calls. +## System Boot + +IRC, freenode, #hurd, 2011-07-27 + + < braunr> btw, was there any formulation of the modifications required to + have disk drivers in userspace ? + < braunr> (which would obviously need something like + initrd/initramfs/whatever and may also need the root file system not to + be the first task started) + < braunr> hm actually, we may not need initrd + < braunr> the boot loader could just load more modules + < antrik> braunr: I have described all that in my thesis report... in + German :-( + < braunr> and the boot scripts could be adjusted to pass around the right + ports + < Tekk_> braunr: yeah, we could probably load a module that kciks us into + userspace and starts the disk driver + < braunr> modules are actualy userspace executables + < Tekk_> ah + < Tekk_> so what's the issue? + < Tekk_> oh! I'm thinking the ext2fs server, which is already in userspce + < braunr> change the file systems to tell them which underlying disk driver + to use + < Tekk_> mhm + < braunr> s/disk/storage/ + # Plan diff --git a/open_issues/wine.mdwn b/open_issues/wine.mdwn index 85d35c9c..65e6c584 100644 --- a/open_issues/wine.mdwn +++ b/open_issues/wine.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -19,3 +19,51 @@ requirements Wine has: only libc / POSIX / etc., or if there are [[Samuel|samuelthibault]] suspects that *there's some need for LDT table allocation. There is kernel support for this,* however. + + +IRC, freenode, #hurd, 2011-08-11 + + < arethusa> I've been trying to make Wine work inside a Debian GNU/Hurd VM, + and to that end, I've successfully compiled the latest sources from Git + after installing the libc (devel) packages from experimental and + personally patching Wine with http://pastebin.com/rg6dx09G + +[[rg6dx09G.patch]] + + < arethusa> my question is, when trying to launch Wine, I'm seeing "wine + client error:0: sendmsg: (os/kern) invalid address" from the client side, + whereas the wineserver seems to be starting and running correctly, how + could I debug this issue further? using rpctrace doesn't seem to help, as + the trace just hangs when run on the Wine loader instead of yielding + insight + < kilobug> arethusa: isn't there a wine debuguer that can start a gdb when + wine encounters an error or something like that ? + < arethusa> it's too early for that + < kilobug> or least give you a full traceback of the wine code where the + error occur ? + < arethusa> the error is happening during initial connect to the + wineserver, in dlls/ntdll/server.c + < arethusa> but that doesn't help me figure out why sendmsg would error out + in this way + < arethusa> + http://source.winehq.org/git/wine.git/blob/HEAD:/dlls/ntdll/server.c#l361 + < azeem_> arethusa: probably some of the msghdr entries are not supported + by the Hurd's glib + < azeem_> c + < pinotree> haha, socket credentials, which we don't support yet + < azeem_> yep + < pinotree> youpi: ↑ another case ;) + < azeem_> arethusa: just implement those and it should work + < kilobug> in pflocal ? or glibc ? + < pinotree> pflocal + < arethusa> azeem_: hmm, okay, thanks + < pinotree> arethusa: their lack is a known issue, and makes things like + dbus and gamin not work + < arethusa> it's + https://www.gnu.org/software/hurd/open_issues/sendmsg_scm_creds.html and + related links I assume? + +[[sendmsg_scm_creds]] + + < youpi> yes + < pinotree> (but that patch is lame) diff --git a/open_issues/wine/rg6dx09G.patch b/open_issues/wine/rg6dx09G.patch new file mode 100644 index 00000000..510ff23f --- /dev/null +++ b/open_issues/wine/rg6dx09G.patch @@ -0,0 +1,116 @@ +diff --git a/dlls/ntdll/directory.c b/dlls/ntdll/directory.c +index 42b3639..7484608 100644 +--- a/dlls/ntdll/directory.c ++++ b/dlls/ntdll/directory.c +@@ -3145,14 +3145,14 @@ static void WINAPI read_changes_user_apc( void *arg, IO_STATUS_BLOCK *io, ULONG + static NTSTATUS read_changes_apc( void *user, PIO_STATUS_BLOCK iosb, NTSTATUS status, void **apc ) + { + struct read_changes_info *info = user; +- char data[PATH_MAX]; ++ char data[4096]; + NTSTATUS ret; + int size; + + SERVER_START_REQ( read_change ) + { + req->handle = wine_server_obj_handle( info->FileHandle ); +- wine_server_set_reply( req, data, PATH_MAX ); ++ wine_server_set_reply( req, data, 4096 ); + ret = wine_server_call( req ); + size = wine_server_reply_size( reply ); + } +diff --git a/dlls/ntdll/signal_i386.c b/dlls/ntdll/signal_i386.c +index 6c8e8e2..e949227 100644 +--- a/dlls/ntdll/signal_i386.c ++++ b/dlls/ntdll/signal_i386.c +@@ -180,6 +180,36 @@ __ASM_GLOBAL_FUNC(vm86_enter, + + #endif /* linux */ + ++#ifdef __GNU__ ++ ++typedef ucontext_t SIGCONTEXT; ++ ++#define EAX_sig(context) ((context)->uc_mcontext.gregs[REG_EAX]) ++#define EBX_sig(context) ((context)->uc_mcontext.gregs[REG_EBX]) ++#define ECX_sig(context) ((context)->uc_mcontext.gregs[REG_ECX]) ++#define EDX_sig(context) ((context)->uc_mcontext.gregs[REG_EDX]) ++#define ESI_sig(context) ((context)->uc_mcontext.gregs[REG_ESI]) ++#define EDI_sig(context) ((context)->uc_mcontext.gregs[REG_EDI]) ++#define EBP_sig(context) ((context)->uc_mcontext.gregs[REG_EBP]) ++#define ESP_sig(context) ((context)->uc_mcontext.gregs[REG_ESP]) ++ ++#define CS_sig(context) ((context)->uc_mcontext.gregs[REG_CS]) ++#define DS_sig(context) ((context)->uc_mcontext.gregs[REG_DS]) ++#define ES_sig(context) ((context)->uc_mcontext.gregs[REG_ES]) ++#define SS_sig(context) ((context)->uc_mcontext.gregs[REG_SS]) ++#define FS_sig(context) ((context)->uc_mcontext.gregs[REG_FS]) ++#define GS_sig(context) ((context)->uc_mcontext.gregs[REG_GS]) ++ ++#define EFL_sig(context) ((context)->uc_mcontext.gregs[REG_EFL]) ++#define EIP_sig(context) ((context)->uc_mcontext.gregs[REG_EIP]) ++#define TRAP_sig(context) ((context)->uc_mcontext.gregs[REG_TRAPNO]) ++#define ERROR_sig(context) ((context)->uc_mcontext.gregs[REG_ERR]) ++ ++#define FPU_sig(context) ((FLOATING_SAVE_AREA *)&(context)->uc_mcontext.fpregs.fp_reg_set.fpchip_state) ++#define FPUX_sig(context) NULL ++ ++#endif /* __GNU__ */ ++ + #ifdef BSDI + + #include +diff --git a/dlls/shell32/shfldr_unixfs.c b/dlls/shell32/shfldr_unixfs.c +index 9649df8..cdd1798 100644 +--- a/dlls/shell32/shfldr_unixfs.c ++++ b/dlls/shell32/shfldr_unixfs.c +@@ -369,7 +369,7 @@ static inline BOOL UNIXFS_is_pidl_of_type(LPCITEMIDLIST pIDL, SHCONTF fFilter) { + static BOOL UNIXFS_get_unix_path(LPCWSTR pszDosPath, char *pszCanonicalPath) + { + char *pPathTail, *pElement, *pCanonicalTail, szPath[FILENAME_MAX], *pszUnixPath, has_failed = 0, mb_path[FILENAME_MAX]; +- WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[PATH_MAX], *dospath_end; ++ WCHAR wszDrive[] = { '?', ':', '\\', 0 }, dospath[MAX_PATH], *dospath_end; + int cDriveSymlinkLen; + void *redir; + +diff --git a/dlls/winex11.drv/xrender.c b/dlls/winex11.drv/xrender.c +index ad8e08b..a8d6329 100644 +--- a/dlls/winex11.drv/xrender.c ++++ b/dlls/winex11.drv/xrender.c +@@ -2440,8 +2440,8 @@ void X11DRV_XRender_UpdateDrawable(X11DRV_PDEVICE *physDev) + return; + } + +-BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, X11DRV_PDEVICE *devSrc, +- struct bitblt_coords *dst, struct bitblt_coords *src, BLENDFUNCTION blendfn ) ++BOOL XRender_AlphaBlend( X11DRV_PDEVICE *devDst, struct bitblt_coords *dst, ++ X11DRV_PDEVICE *devSrc, struct bitblt_coords *src, BLENDFUNCTION blendfn ) + { + FIXME("not supported - XRENDER headers were missing at compile time\n"); + return FALSE; +diff --git a/libs/wine/ldt.c b/libs/wine/ldt.c +index 3098061..b3fee13 100644 +--- a/libs/wine/ldt.c ++++ b/libs/wine/ldt.c +@@ -96,6 +96,11 @@ static inline int set_thread_area( struct modify_ldt_s *ptr ) + #include + #endif + ++#ifdef __GNU__ ++#include ++#include ++#endif ++ + /* local copy of the LDT */ + #ifdef __APPLE__ + struct __wine_ldt_copy wine_ldt_copy = { { 0, 0, 0 } }; +@@ -203,6 +208,9 @@ static int internal_set_entry( unsigned short sel, const LDT_ENTRY *entry ) + #elif defined(__APPLE__) + if ((ret = i386_set_ldt(index, (union ldt_entry *)entry, 1)) < 0) + perror("i386_set_ldt"); ++#elif defined(__GNU__) ++ if ((ret = i386_set_ldt(mach_thread_self(), sel, (descriptor_list_t)entry, 1)) != KERN_SUCCESS) ++ perror("i386_set_ldt"); + #else + fprintf( stderr, "No LDT support on this platform\n" ); + exit(1); \ No newline at end of file -- cgit v1.2.3 From 278f76de415c83bd06146b2f25a002cf0411d025 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 6 Sep 2011 16:02:51 +0200 Subject: IRC. --- microkernel/mach/memory_object/discussion.mdwn | 43 ++- open_issues/clock_gettime.mdwn | 30 ++ open_issues/default_pager.mdwn | 28 ++ open_issues/gnumach_memory_management.mdwn | 92 ++++++ open_issues/mach_migrating_threads.mdwn | 15 + open_issues/performance.mdwn | 8 + open_issues/performance/degradation.mdwn | 14 +- open_issues/performance/ipc_virtual_copy.mdwn | 358 +++++++++++++++++++++ open_issues/time.mdwn | 16 +- .../translators_set_up_by_untrusted_users.mdwn | 43 +++ 10 files changed, 644 insertions(+), 3 deletions(-) create mode 100644 open_issues/default_pager.mdwn create mode 100644 open_issues/mach_migrating_threads.mdwn create mode 100644 open_issues/performance/ipc_virtual_copy.mdwn (limited to 'microkernel/mach') diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn index a006429b..c874b255 100644 --- a/microkernel/mach/memory_object/discussion.mdwn +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -10,7 +10,7 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_gnumach]] -IRC, freenode, #hurd, 2011-08-05 +IRC, freenode, #hurd, 2011-08-05: < neal> braunr: For instance, memory objects are great as they allow you to specify the mapping policy in user space. @@ -22,3 +22,44 @@ IRC, freenode, #hurd, 2011-08-05 < neal> I'm not sure what you mean by page cache lru appoximateion < braunr> the kernel eviction policy :) < neal> that's an implementation detail + +IRC, freenode, #hurd, 2011-09-05: + + mach isn't a true modern microkernel, it handles a lot of + resources, such as high level virtual memory and cpu time + for example, the page replacement mechanism can't be implemented + outside the kernel + yet, it provides nothing to userspace server to easily allocate + resources on behalf of clients + so, when a thread calls an RPC, the cpu time used to run that RPC + is accounted on the server task + the hurd uses lots of external memory managers + +[[external_pager_mechanism]]. + + but they can't decide how to interact with the page cache + the kernel handles the page cache, and initiates the requests to + the pagers + braunr, why can't they decide that? + because it's implemented in the kernel + and there is nothing provided by mach to do that some other way + braunr: you probably already know this, but the problem with client + requests being accounted on behalf the server, is fixed in Mach with + Migrating Threads + +[[open_issues/mach_migrating_threads]]. + + slpz_: migrating threads only fix the issue for the resources + managed by mach, not the external servers + slpz_: but it's a (imo necessary) step to completely solve the + issue + in addition to being a great feature for performance (lighter + context switchers, less state to track) + it also helps priority inversion problems + braunr: I was referring just to cpu-time, but I agree with you an + interface change is needed for external pagers + slpz_: servers in general, not necessarily pagers + as a way to mitigate the effect of Mach paging out to external + pagers, the folks at OSF implemented an "advisory pageout", so servers + are "warned" that they should start paging out, and can decide which + pages are going to be flushed by themselves diff --git a/open_issues/clock_gettime.mdwn b/open_issues/clock_gettime.mdwn index c06edc9b..5345ed6b 100644 --- a/open_issues/clock_gettime.mdwn +++ b/open_issues/clock_gettime.mdwn @@ -39,3 +39,33 @@ IRC, freenode, #hurd, 2011-08-26: < youpi> yes, it should work < braunr> sure < youpi> and that's the way I was considering implementing it + +IRC, freenode, #hurd, 2011-09-06: + + yeah, i had a draft of improved idea for also handling + nanoseconds + pinotree: Ah, nice, I thought about nanoseconds as well. + pinotree, youpi: This memory page is all-zero by default, + right? + Can't we then say that its last int is a version code, and if + it is 0 (as it is now), we only have the normal mapped time field, if it + is 1, we also have the monotonic cliock and ns precision on address 8 and + 16 (or whatever)? + In case that isn't your plan anyway. + it's all-zero, yes + Or, we say if a field is != 0 it is valid. + making the last int a version code limits the size to one page + I was thinking a field != 0 being valid is simpler + but it's probably a problem too + in that glibc usually caches whether interfaces are supported + Wrap-around? + for some clocks, it may be valid that the value is 0 + wrap-around is another issue too + Well, then we can do the version-field thing, but put it right + after the current time field (address 8, I think)? + yes + it's a bit ugly, but it's hidden behind the structure + It's not too bad, I think. + yes + And it will forever be a witness of the evolving of this + map_time interface. :-) diff --git a/open_issues/default_pager.mdwn b/open_issues/default_pager.mdwn new file mode 100644 index 00000000..189179c6 --- /dev/null +++ b/open_issues/default_pager.mdwn @@ -0,0 +1,28 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + +IRC, freenode, #hurd, 2011-08-31: + + braunr: do you have any idea what could cause the paging errors + long before swap is exhausted? + antrik: not really, but i know every project based on the mach vm + have rewritten their swap pager + (and also I/O performance steadily dropping before that point is + reached?) + hm + there could too many things + perhaps we could "borrow" from one of them? :-) + map entry fragmentation for example + the freebsd one is the only possible candidate + uvm is too different + dragonflybsd maybe, but it's very close to freebsd + i didn't look at darwin/xnu diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn index a728fc9d..1fe2f9be 100644 --- a/open_issues/gnumach_memory_management.mdwn +++ b/open_issues/gnumach_memory_management.mdwn @@ -1320,3 +1320,95 @@ There is a [[!FF_project 266]][[!tag bounty]] on this task. < braunr> i hope it helped you learn about memory allocation, virtual memory, gnu mach and the hurd in general :) < antrik> indeed :-) + + +# IRC, freenode, #hurd, 2011-09-06 + + [some performance testing] + i'm not sure such long tests are relevant but let's assume balloc + is slower + some tuning is needed here + first, we can see that slab allocation occurs more often in balloc + than page allocation does in zalloc + so yes, as slab allocation is slower (have you measured which part + actually is slow ? i guess it's the kmem_alloc call) + the whole process gets a bit slower too + I used alloc_size = 4096 for zalloc + i don't know what that is exactly + but you can't hold 500 16 bytes buffers in a page so zalloc must + have had free pages around for that + I use kmem_alloc_wired + if you have time, measure it, so that we know how much it accounts + for + where are the results for dealloc ? + I can't give you result right now because internet works very + bad. But for first DEALLOC result are the same, exept some cases when it + takes balloc for more than 1000 ticks + must be the transfer from the cpu layer to the slab layer + as to kmem_alloc_wired. I think zalloc uses this function too for + allocating objects in zone I test. + mcsim: yes, but less frequently, which is why it's faster + mcsim: another very important aspect that should be measured is + memory consumption, have you looked into that ? + I think that I made too little iterations in test SMALL + If I increase constant SMALL_TESTS will it be good enough? + mcsim: i don't know, try both :) + if you increase the number of iterations, balloc average time will + be lower than zalloc, but this doesn't remove the first long + initialization step on the allocated slab + SMALL_TESTS to 500, I mean + i wonder if maintaining the slabs sorted through insertion sort is + what makes it slow + braunr: where do you sort slabs? I don't see this. + mcsim: mem_cache_alloc_from_slab and its free counterpart + mcsim: the mem_source stuff is useless in gnumach, you can remove + it and directly call the kmem_alloc/free functions + But I have to make special allocator for kernel map entries. + ah right + btw. It turned out that 256 entries are not enough. + that's weird + i'll make a patch so that the mem_source code looks more like what + i have in x15 then + about the results, i don't think the slab layer is that slow + it's the cpu_pool_fill/drain functions that take time + they preallocate many objects (64 for your objects size if i'm + right) at once + mcsim: look at the first result page: some times, a number around + 8000 is printed + the common time (ticks, whatever) for a single object is 120 + 8132/120 is 67, close enough to the 64 value + I forgot about SMALL tests here are they: + http://paste.debian.net/128533/ (balloc) http://paste.debian.net/128534/ + (zalloc) + braunr: why do you divide 8132 by 120? + mcsim: to see if it matches my assumption that the ~8000 number + matches the cpu_pool_fill call + braunr: I've got it + mcsim: i'd be much interested in the dealloc results if you can + paste them too + dealloc: http://paste.debian.net/128589/ + http://paste.debian.net/128590/ + mcsim: thanks + second dealloc: http://paste.debian.net/128591/ + http://paste.debian.net/128592/ + mcsim: so the main conclusion i retain from your tests is that the + transfers from the cpu and the slab layers are what makes the new + allocator a bit slower + OPERATION_SMALL dealloc: http://paste.debian.net/128593/ + http://paste.debian.net/128594/ + mcsim: what needs to be measured now is global memory usage + braunr: data from /proc/vmstat after kernel compilation will be + enough? + mcsim: let me check + mcsim: no it won't do, you need to measure kernel memory usage + the best moment to measure it is right after zone_gc is called + Are there any facilities in gnumach for memory measurement? + it's specific to the allocators + just count the number of used pages + after garbage collection, there should be no free page, so this + should be rather simple + ok + braunr: When I measure memory usage in balloc, what formula is + better cache->nr_slabs * cache->bufs_per_slab * cache->buf_size or + cache->nr_slabs * cache->slab_size? + the latter diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn new file mode 100644 index 00000000..5a70aac5 --- /dev/null +++ b/open_issues/mach_migrating_threads.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_gnumach]] + + + + * [[microkernel/mach/memory_object/discussion]] diff --git a/open_issues/performance.mdwn b/open_issues/performance.mdwn index 54f3ce39..2fd34621 100644 --- a/open_issues/performance.mdwn +++ b/open_issues/performance.mdwn @@ -30,3 +30,11 @@ call|/glibc/fork]]'s case. --- * [[Degradation]] + + * [[fork]] + + * [[IPC_virtual_copy]] + + * [[microbenchmarks]] + + * [[microkernel_multi-server]] diff --git a/open_issues/performance/degradation.mdwn b/open_issues/performance/degradation.mdwn index 5db82e31..db759308 100644 --- a/open_issues/performance/degradation.mdwn +++ b/open_issues/performance/degradation.mdwn @@ -18,7 +18,7 @@ Thomas Schwinge) > tree, reboot, build it again (1st): back to 11 h. Remove build tree, build > it again (2nd): 12 h 40 min. Remove build tree, build it again (3rd): 15 h. -IRC, freenode, #hurd, 2011-07-23 +IRC, freenode, #hurd, 2011-07-23: < antrik> tschwinge: yes, the system definitely gets slower with time. after running for a couple of weeks, it needs at least twice as @@ -26,3 +26,15 @@ IRC, freenode, #hurd, 2011-07-23 < antrik> I don't know whether this is only related to swap usage, or there are some serious fragmentation issues < braunr> antrik: both could be induced by fragmentation + +--- + +During [[IPC_virtual_copy]] testing: + +IRC, freenode, #hurd, 2011-09-02: + + interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + manuel: i observed the same behaviour + [...] diff --git a/open_issues/performance/ipc_virtual_copy.mdwn b/open_issues/performance/ipc_virtual_copy.mdwn new file mode 100644 index 00000000..00fa7180 --- /dev/null +++ b/open_issues/performance/ipc_virtual_copy.mdwn @@ -0,0 +1,358 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +IRC, freenode, #hurd, 2011-09-02: + + what's the usual throughput for I/O operations (like "dd + if=/dev/zero of=/dev/null") in one of those Xen based Hurd machines + (*bber)? + good question + slpz: but don't use /dev/zero and /dev/null, as they don't have + anything to do with true I/O operations + braunr: in fact, I want to test the performance of IPC's virtual + copy operations + ok + braunr: sorry, the "I/O" was misleading + use bs=4096 then i guess + bs > 2k + ? + braunr: everything about 2k is copied by vm_map_copyin/copyout + s/about/above/ + braunr: MiG's stubs check for that value and generate complex (with + out_of_line memory) messages if datalen is above 2k, IIRC + ok + slpz: found it, thanks + tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + [1] 13469 + 17091+0 records in + 17090+0 records out + 70000640 bytes (70 MB) copied, 17.1436 s, 4.1 MB/s + Note, however 10 s vs. 17 s! + And this is slow compared to heal hardware: + thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=4k & p=$! && + sleep 10 && kill -s INFO $p && sleep 1 && kill $p + [1] 28290 + 93611+0 records in + 93610+0 records out + 383426560 bytes (383 MB) copied, 9.99 s, 38.4 MB/s + tschwinge: is the first result on xen vm ? + I think so. + :/ + tschwinge: Thanks! Could you please try with a higher block size, + something like 128k or 256k? + strauss is on a machine that also hosts a buildd, I think. + oh ok + yes, aside either rossini or mozart + And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). + +[[open_issues/time]] + + slpz: i'll set up xen hosts soon and can try those tests while + nothing else runs to have more accurate results + tschwinge@strauss:~ $ dd if=/dev/zero of=/dev/null bs=256k & + p=$! && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + [1] 13482 + 4566+0 records in + 4565+0 records out + 1196687360 bytes (1.2 GB) copied, 13.6751 s, 87.5 MB/s + slpz: gains are logarithmic beyond the page size + thomas@coulomb:~ $ dd if=/dev/zero of=/dev/null bs=256k & p=$! + && sleep 10 && kill -s INFO $p && sleep 1 && kill $p + [1] 28295 + 6335+0 records in + 6334+0 records out + 1660420096 bytes (1.7 GB) copied, 9.99 s, 166 MB/s + This time a the sleep 10 decided to take 13.6 s. + ``Interesting.'' + tschwinge: Thanks again. The results for the Xen machine are not bad + though. I can't obtain a throughput over 50MB/s with KVM. + slpz: Want more data (bs)? Just tell. + slpz: i easily get more than that + slpz: what buffer size do you use ? + tschwinge: no, I just wanted to see if Xen has an upper limit beyond + KVM's. Thank you. + braunr: I try with different sizes until I find the maximum + throughput for a certain amount of requests (count) + braunr: are you working with KVM? + yes + slpz: my processor is a model name : Intel(R) Core(TM)2 Duo + CPU E7500 @ 2.93GHz + Linux silvermoon 2.6.32-5-amd64 #1 SMP Tue Jun 14 09:42:28 UTC + 2011 x86_64 GNU/Linux + (standard amd64 squeeze kernel) + braunr: and KVM's version? + squeeze (0.12.5) + bbl + 212467712 bytes (212 MB) copied, 9.95 s, 21.4 MB/s on kvm for me! + gnu_srs: which block size? + 4k, and 61.7 MB/s with 256k + gnu_srs: could you try with 512k and 1M? + 512k: 56.0 MB/s, 1024k: 40.2 MB/s Looks like the peak is around a + few 100k + gnu_srs: thanks! + I've just obtained 1.3GB/s with bs=512k on other (newer) machine + on which hw/vm ? + I knew this is a cpu-bound test, but I couldn't imagine faster + processors could make this difference + braunr: Intel(R) Core(TM) i5 CPU 650 @ 3.20GHz + braunr: KVM + ok + how much time did you wait before reading the result ? + that was 20x times better than the same test on my Intel(R) + Core(TM)2 Duo CPU T7500 @ 2.20GHz + braunr: I've repeated the test with a fixed "count" + My box is: Intel(R) Core(TM)2 Quad CPU Q6600 @ 2.40GHz: Max + is 67 MB/s around 140k block size + yes but how much time did dd run ? + 10 s plus/minus a few fractions of a second, + try waiting 30s + braunr: didn't check, let me try again + my kvm peaks at 130 MiB/s with bs 512k / 1M + 2029690880 bytes (2.0 GB) copied, 30.02 s, 67.6 MB/s, bs=140k + gnu_srs: i'm very surprised with slpz's result of 1.3 GiB/s + braunr: over 60 s running, same performance + nice + i wonder what makes it so fast + how much cache ? + Me too, I cannot get better values than around 67 MB/s + gnu_srs: same questions + braunr: 4096KB, same as my laptop + slpz: l2 ? l3 ? + kvm: cache=writeback, CPU: 4096 KB + gnu_srs: this has nothing to do with the qemu option, it's about + the cpu + braunr: no idea, it's the first time I touch this machine. I going + to see if I find the model in processorfinder + under my host linux system, i get a similar plot, that is, + performance drops beyond bs=1M + braunr: OK, bu I gave you the cache size too, same as slpz. + i wonder what dd actually does + read() and writes i guess + braunr: read/write repeatedly, nothing fancy + slpz: i don't think it's a good test for virtual copy + io_read_request, vm_deallocate, io_write_request, right + slpz: i really wonder what it is about i5 that improves speed so + much + braunr: me too + braunr: L2: 2x256KB, L3: 4MB + and something calling "SmartCache" + slpz: where did you find these values? + gnu_srs: ark.intel.com and wikipedia + aha, cpuinfo just gives cache size. + that "SmartCache" thing seems to be just L2 cache sharing between + cores. Shouldn't make a different since we're using only one core, and I + don't see KVM hooping between them. + with bs=256k: 7004487680 bytes (7.0 GB) copied, 10 s, 700 MB/s + (qemu/kvm, 3 * Intel(R) Xeon(R) E5504 2GHz, cache size 4096 KB) + manuel: did you try with 512k/1M? + bs=512k: 7730626560 bytes (7.7 GB) copied, 10 s, 773 MB/s + bs=1M: 7896825856 bytes (7.9 GB) copied, 10 s, 790 MB/s + manuel: those are pretty good numbers too + xeon processor + lshw gave me: L1 Cache 256KiB, L2 cache 4MiB + sincerely, I've never seen Hurd running this fast. Just checked + "uname -a" to make sure I didn't take the wrong image :-) + for bs=256k, 60s: 40582250496 bytes (41 GB) copied, 60 s, 676 MB/s + slpz: i think you can assume processor differences alter raw + copies too much to get any valuable results about virtual copy operations + you need a specialized test program + and bs=512k, 60s, 753 MB/s + braunr: I'm using the mach_perf suite from OSFMach to do the + "serious" testing. I just wanted a non-synthetic test to confirm the + readings. + +[[!taglink open_issue_gnumach]] -- have a look at *mach_perf*. + + manuel: how much cache ? 2M ? + slpz: ok + manuel: hmno, more i guess + braunr: /proc/cpuinfo says cache size : 4096 KB + ok + manuel: performance should drop beyond bs=2M + but that's not relevant anyway + Linux: bs=1M, 10.8 GB/s + I think this difference is too big to be only due to a bigger amount + of CPU cycles... + slpz: clearly + gnu_srs: your host system has 64 or 32 bits? + braunr: I'm going to investigate a bit + but this accidental discovery just made my day. We're able to run + Hurd at decent speeds on newer hardware! + slpz: what result do you get with the same test on your host + system ? + interestingly, running it several times has made the performance + drop quite much (i'm getting 400-500MB/s with 1M now, compared to nearly + 800 fifteen minutes ago) + +[[Degradataion]]. + + braunr: probably an almost infinite throughput, but I don't consider + that a valid test, since in Linux, the write operation to "/dev/null" + doesn't involve memory copying/moving + manuel: i observed the same behaviour + slpz: Host system is 64 bit + slpz: it doesn't on the hurd either + slpz: (under 2k, that is) + over* + braunr: humm, you're right, as the null translator doesn't "touch" + the memory, CoW rules apply + slpz: the only thing which actually copies things around is dd + probably by simply calling read() + which gets its result from a VM copy operation, but copies the + content to the caller provided buffer + then vm_deallocate() the data from the storeio (zero) translator + if storeio isn't too dumb, it doesn't even touch the transfered + buffer (as anonymous vm_map()ped memory is already cleared) + +[[!taglink open_issue_documentation]] + + so this is a good test for measuring (profiling?) our ipc overhead + and possibly the vm mapping operations (which could partly explain + why the results get worse over time) + manuel: can you run vminfo | wc -l on your gnumach process ? + braunr: Yes, unless some special situation apply, like the source + address/offset being unaligned, or if the translator decides to return + the result in a different buffer (which I assume is not the case for + storeio/zero) + braunr: 35 + slpz: they can't be unaligned, the vm code asserts that + manuel: ok, this is normal + braunr: address/offset from read() + slpz: the caller provided buffer you mean ? + braunr: yes, and the offset of the memory_object, if it's a pager + based translator + slpz: highly unlikely, the compiler chooses appropriate alignments + for such buffers + braunr: in those cases, memcpy is used over vm_copy + slpz: and the glibc memcpy() optimized versions can usually deal + with that + slpz: i don't get your point about memory objects + slpz: requests on memory objects always have aligned values too + braunr: sure, but can't deal with the user requesting non + page-aligned sizes + slpz: we're considering our dd tests, for which we made sure sizes + were page aligned + braunr: oh, I was talking in a general sense, not just in this dd + tests, sorry + by the way, dd on the host tops at 12 GB/s with bs=2M + that's consistent with our other results + slpz: you mean, even on your i5 processor with 1.3 GiB/s on your + hurd kvm ? + braunr: yes, on the GNU/Linux which is running as host + slpz: well that's not consistent + braunr: consistent with what? + slpz: i get roughly the same result on my host, but ten times less + on my hurd kvm + slpz: what's your kernel/kvm versions ? + 2.6.32-5-amd64 (debian's build) 0.12.5 + same here + i'm a bit clueless + why do i only get 130 MiB/s where you get 1.3 .. ? :) + well, on my laptop, where Hurd on KVM tops on 50 MB/s, Linux gets a + bit more than 10 GB/s + see + slpz: reduce bs to 256k and test again if you have time please + braunr: on which system? + slpz: the fast one + (linux host) + braunr: Hurd? + ok + 12 GB/s + i get 13.3 + same for 128k, only at 64k starts dropping + maybe, on linux we're being limited by memory speed, while on Hurd's + this test is (much) more CPU-bound? + slpz: maybe + too bad processor stalls aren't easy to measure + braunr: that's very true. It's funny when you read a paper which + measures performance by cycles on an old RISC processor. That's almost + impossible to do (with reliability) nowadays :-/ + I wonder which throughput can achieve Hurd running bare-metal on + this machine... + both the Xeon and the i5 use cores based on the Nehalem + architecture + apparently Nehalem is where Intel first introduces nested page + tables + which pretty much explains the considerably lower overhead of VM + magic + antrik, what are nested page tables? (sounds like the 4-level page + tables we already have on amd64, or 2-level or 3-level on x86 pae) + page tables were always 2-level on x86 + that's unrelated + nested page tables means there is another layer of address + translation, so the VMM can do it's own translation and doesn't care what + the guest system does => no longer has to intercept all page table + manipulations + antrik: do you imply it only applies to virtualized systems ? + braunr: yes + antrik: Good guess. Looks like Intel's EPT are doing the trick by + allowing the guest OS deal with its own page faults + antrik: next monday, I'll try disabling EPT support in KVM on that + machine (the fast one). That should confirm your theory empirically. + this also means that there're too many page faults, as we should be + doing virtual copies of memory that is not being accessed + and looking at how the value of "page faults" in "vmstat" increases, + shows that page faults are directly proportional to the number of pages + we are asking from the translator + I've also tried doing a long read() directly, to be sure that "dd" + is not doing something weird, and it shows the same behaviour. + slpz: dd does copy buffers + slpz: i told you, it's not a good test case for pure virtual copy + evaluation + antrik: do you know if xen benefits from nested page tables ? + no idea + +[[!taglink open_issue_xen]] + + braunr: but my small program doesn't, and still provokes a lot of + page faults + slpz: are you certain it doesn't ? + braunr: looking at google, it looks like recent Xen > 3.4 supports + EPT + ok + i'm ordering my new server right now, core i5 :) + braunr: at least not explicitily. I need to look at MiG stubs again, + I don't remember if they do something weird. + braunr: sandybridge or nehalem? :-) + antrik: no idea + does it tell a model number? + not yet + but i don't have a choice for that, so i'll order it first, check + after + hehe + I'm not sure it makes all that much difference anyways for a + server... unless you are running it at 100% load ;-) + antrik: i'm planning on running xen guests suchs as new buildd + hm... note though that some of the nehalem-generation i5s were + dual-core, while all the new ones are quad + it's a quad + the newer generation has better performance per GHz and per + Watt... but considering that we are rather I/O-limited in most cases, it + probably won't make much difference + not sure whether there are further virtualisation improvements + that could be relevant... + buildds spend much time running gcc, so even such improvements + should help + there, server ordered :) + antrik: model name : Intel(R) Core(TM) i5-2400 CPU @ 3.10GHz + +IRC, freenode, #hurd, 2011-09-06: + + youpi: what machines are being used for buildd? Do you know if they + have EPT/RVI? + we use PV Xen there + I think Xen could also take advantage of those technologies. Not + sure if only in HVM or with PV too. + only in HVM + in PV it does not make sense: the guest already provides the + translated page table + which is just faster than anything else diff --git a/open_issues/time.mdwn b/open_issues/time.mdwn index eda5b635..ab239aef 100644 --- a/open_issues/time.mdwn +++ b/open_issues/time.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2009 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -53,3 +53,17 @@ GNU time's *elapsed* value is off by some factor. As above; also here all the running time should be attriuted to *user* time. This is probably a [[!taglink open_issue_gnumach]]. + + +# 2011-09-02 + +Might want to revisit this, and take Xen [[!tag open_issue_xen]] into account +-- I believe flubber has already been Xenified at that time. + + +## IRC, freenode, #hurd, 2011-09-02 + +While testing some [[performance/IPC_virtual_copy]] performance issues: + + And I can confirm that with dd if=/dev/zero of=/dev/null bs=4k + running, a parallel sleep 10 takes about 20 s (on strauss). diff --git a/open_issues/translators_set_up_by_untrusted_users.mdwn b/open_issues/translators_set_up_by_untrusted_users.mdwn index cee7a2bc..36fe5438 100644 --- a/open_issues/translators_set_up_by_untrusted_users.mdwn +++ b/open_issues/translators_set_up_by_untrusted_users.mdwn @@ -281,3 +281,46 @@ Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Symlink and [Hardlink Protection](https://wiki.ubuntu.com/SecurityTeam/Roadmap/KernelHardening#Hardlink_Protection) do bear some similarity with the issue we're discussing here. + + +# IRC, freenode, #hurd, 2011-08-31 + + I don't see any problems with following only translators of + trusted users + where to store the list of trusted users? + is there a way to access the underlying node, which for /dev + entries belongs to root? + youpi: why a list of trusted users? Does it not suffice to + require /hurd/trust set by root or ourselves? + ArneBab: just because that's what antrik suggests, so I ask him for + more details + ah, ok + youpi: probably make them members of a group + of course that doesn't allow normal users to add their own trusted + users... but that's not the only limitation of the user-based + authentication mechanism, so I wouldn't consider that an extra problem + ArneBab: we can't set a translator on top of another user's + translator in general + root could, but that's not very flexible... + the group-based solution seems more useful to me + antrik: why can’t we? + also note that you can't set passive translators on top of other + translators + ArneBab: because we can only set translators on our own nodes + active ones, too? + yes + antrik: I always thought I could… + but did not test it + antrik: so I need a subhurd to change nodes which do not belong + to me? + * ArneBab in that case finally understands why you like subhurds so much: + That should be my normal right + it should be your normal right to change stuff not belonging to + you? that's an odd world view :-) + subhurds don't really have anything to do with it + change it in a way that only I see the changes + you need local namespaces to allow making local modifications to + global resources + it should be one's normal right to change the view one has of it + we discussed that once actually I believe... + err... private namespaces I mean -- cgit v1.2.3 From 647faa6dd7e286d20171247039bd59600bb7e436 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Tue, 6 Sep 2011 16:33:37 +0200 Subject: microkernel/mach/gnumach/boot_trace: Update lightly. --- microkernel/mach/gnumach/boot_trace.mdwn | 13 ++++++++++--- 1 file changed, 10 insertions(+), 3 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/boot_trace.mdwn b/microkernel/mach/gnumach/boot_trace.mdwn index d33ef25a..1badf712 100644 --- a/microkernel/mach/gnumach/boot_trace.mdwn +++ b/microkernel/mach/gnumach/boot_trace.mdwn @@ -1,12 +1,13 @@ -[[!meta copyright="Copyright © 2007, 2008 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2007, 2008, 2011 Free Software Foundation, +Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this document under the terms of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled -[[GNU Free Documentation License|/fdl]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] `if NCPUS > 1` stuff is not being considered so far. @@ -215,6 +216,12 @@ is included in the section entitled >> kern/bootstrap.c: bootstrap\_create +>>> The [[grub/multiboot]] modules have been put somewhere into memory by +>>> [[GRUB]]. The boot scripts are parsed. The modules' ELF image's `PT_LOAD` +>>> sections are \`\`read'' (that is, `vm_allocate` and `copyout`) and turned +>>> into real [[task]]s. The multiboot modules' memory regions can be +>>> deallocated then. + >> [...] >> vm\_pageout -- cgit v1.2.3 From 331da015205c6b18c0e0f9cbfd0d02a931ee5239 Mon Sep 17 00:00:00 2001 From: Samuel Thibault Date: Wed, 7 Sep 2011 19:19:48 +0200 Subject: fix urls --- microkernel/mach/gnumach/building.mdwn | 2 +- microkernel/mach/mig/gnu_mig/building.mdwn | 2 +- 2 files changed, 2 insertions(+), 2 deletions(-) (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/building.mdwn b/microkernel/mach/gnumach/building.mdwn index afcfac74..427fb083 100644 --- a/microkernel/mach/gnumach/building.mdwn +++ b/microkernel/mach/gnumach/building.mdwn @@ -21,7 +21,7 @@ enabled) is around 50 MiB. You can either use the git repository (see ), - $ git clone git.savannah.gnu.org:/srv/git/hurd/gnumach.git + $ git clone http://git.savannah.gnu.org/cgit/hurd/gnumach.git/ ... or get the Debian sources, if you're using Debian. (See [here](http://packages.debian.net/source/unstable/gnumach).) diff --git a/microkernel/mach/mig/gnu_mig/building.mdwn b/microkernel/mach/mig/gnu_mig/building.mdwn index cd588341..e7d3c150 100644 --- a/microkernel/mach/mig/gnu_mig/building.mdwn +++ b/microkernel/mach/mig/gnu_mig/building.mdwn @@ -19,7 +19,7 @@ using a pre-built package, follow these instructions. You can chose between getting the [sources from the developers' RCS](http://git.savannah.gnu.org/cgit/hurd/): - $ git clone git://git.savannah.gnu.org:/srv/git/hurd/mig.git + $ git clone http://git.savannah.gnu.org/cgit/hurd/mig.git/ ... or (if you are working on a Debian system) get the sources that are used for the [current Debian mig package](http://packages.debian.net/source/unstable/mig): -- cgit v1.2.3 From 27d0672395f8f9121733e1e8cdddfa3f0717ef1d Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Fri, 9 Sep 2011 10:10:50 +0200 Subject: Link. --- microkernel/mach/memory_object/discussion.mdwn | 2 ++ open_issues/mach_migrating_threads.mdwn | 2 ++ 2 files changed, 4 insertions(+) (limited to 'microkernel/mach') diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn index c874b255..a2a1514b 100644 --- a/microkernel/mach/memory_object/discussion.mdwn +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -63,3 +63,5 @@ IRC, freenode, #hurd, 2011-09-05: pagers, the folks at OSF implemented an "advisory pageout", so servers are "warned" that they should start paging out, and can decide which pages are going to be flushed by themselves + +[[open_issues/resource_management_problems]]. diff --git a/open_issues/mach_migrating_threads.mdwn b/open_issues/mach_migrating_threads.mdwn index 5a70aac5..c14ce95a 100644 --- a/open_issues/mach_migrating_threads.mdwn +++ b/open_issues/mach_migrating_threads.mdwn @@ -13,3 +13,5 @@ License|/fdl]]."]]"""]] * [[microkernel/mach/memory_object/discussion]] + + * [[resource_management_problems]] -- cgit v1.2.3 From a595c644e0a4438c3acbf3be5e88659b668a8053 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 14 Sep 2011 23:21:09 +0200 Subject: open_issues/mach_on_top_of_posix: New. --- microkernel/mach/gnumach/ports.mdwn | 8 +++++--- open_issues/mach_on_top_of_posix.mdwn | 16 ++++++++++++++++ 2 files changed, 21 insertions(+), 3 deletions(-) create mode 100644 open_issues/mach_on_top_of_posix.mdwn (limited to 'microkernel/mach') diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn index afc91d7a..f114460c 100644 --- a/microkernel/mach/gnumach/ports.mdwn +++ b/microkernel/mach/gnumach/ports.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2009 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -6,8 +6,8 @@ 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]]."]]"""]] +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] * x86. This is the main port. @@ -20,3 +20,5 @@ is included in the section entitled started, but isn't in a usable state either. * MIPS. Status completely unknown. + + * [[open_issues/Mach_on_Top_of_POSIX]]. Status unknown. diff --git a/open_issues/mach_on_top_of_posix.mdwn b/open_issues/mach_on_top_of_posix.mdwn new file mode 100644 index 00000000..7574feb0 --- /dev/null +++ b/open_issues/mach_on_top_of_posix.mdwn @@ -0,0 +1,16 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!meta title="Mach on Top of POSIX"]] + +[[!tag open_issue_gnumach]] + +At the beginning of the 2000s, there was a *Mach on Top of POSIX* port started +by John Edwin Tobey. Status unknown. Ask [[tschwinge]] for the source code. -- cgit v1.2.3 From 3105441d1bf348b225c0778e18f3c9594e5e47ec Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Thu, 15 Sep 2011 13:57:17 +0200 Subject: capability: Extend. --- capability.mdwn | 106 +++++++++++++++++++++++++++++++++++++++- microkernel/eros.mdwn | 15 ++++++ microkernel/mach/port.mdwn | 24 +++++---- open_issues/multithreading.mdwn | 3 +- persistency.mdwn | 25 +++++++++- unix/file_descriptor.mdwn | 3 +- 6 files changed, 162 insertions(+), 14 deletions(-) create mode 100644 microkernel/eros.mdwn (limited to 'microkernel/mach') diff --git a/capability.mdwn b/capability.mdwn index d78810d5..ddadf137 100644 --- a/capability.mdwn +++ b/capability.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -28,6 +28,110 @@ sent a string to identify the file to B, the identifier lacks a than A intended. Be ensuring that [[designation]] and [[authorization]] are always bound together, these problems are avoided. +Capability-based system architectures strive to meet the *principle of least +privilege* ({{$wikipedia_polp}}). + +[[!tag open_issue_documentation]] + +A capability mechanism is typically implemented in software my the operating +system kernel (typically a [[microkernel]]. The computing cost (as compared to +a hardware implementation) is neglectable. + + +[[!tag open_issue_documentation]] + + +[[!tag open_issue_documentation]] + + +# UNIX + [[UNIX file descriptors|unix/file_descriptor]] can be viewed as capabilities. They do not survive reboot, that is, they are not [[persistent|persistency]]. To work around this, [[ACL]]s are used to recover authority. + + +# GNU/Hurd + +In the GNU/Hurd system, a capability is represented by a [[Mach +port|microkernel/mach/port]]. As in UNIX (see above), they are not +[[persistent|persistency]]. + + +# Further Reading + + * [[Mach port|microkernel/mach/port]] + +[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note +text="*[[shapiro\_capintro\_1999|capability]]*: +{{$capability#shapiro_capintro_1999}}. +{{$capability#shapiro_capintro_1999_text}}."]]"""]] + + * [[!toggle id=shapiro_capintro_1999 text="[shapiro\_capintro\_1999]"]] + + * {{$wikipedia_capability-based_security}} + + * {{$wikipedia_object-capability_model}} + + * {{$wikipedia_polp}} + + +[[!tag open_issue_documentation]] + + +[[!ymlfront data=""" + +shapiro_capintro_1999: + + "[What *is* a Capability, + Anyway?](http://www.eros-os.org/essays/capintro.html), Jonathan Shapiro, + 1999" + +shapiro_capintro_1999_text: + + "This is an easily readable introduction with good examples. In the author's + own words, the text *provides a layman's introduction to capabilities, + describing what they are, what they do, and why they result in better + security than today's computer systems*" + +wikipedia_capability-based_security: + + "[[!wikipedia Capability-based_security desc=\"Wikipedia, capability-based + security\"]]" + +wikipedia_object-capability_model: + + "[[!wikipedia Object-capability_model desc=\"Wikipedia, object-capability + model\"]]" + +wikipedia_polp: + + "[[!wikipedia Principle_of_least_privilege desc=\"Wikipedia, principle of + least privilege\"]]" + +"""]] diff --git a/microkernel/eros.mdwn b/microkernel/eros.mdwn new file mode 100644 index 00000000..be1ca90a --- /dev/null +++ b/microkernel/eros.mdwn @@ -0,0 +1,15 @@ +[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] + +[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable +id="license" text="Permission is granted to copy, distribute and/or modify this +document under the terms of the GNU Free Documentation License, Version 1.2 or +any later version published by the Free Software Foundation; with no Invariant +Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license +is included in the section entitled [[GNU Free Documentation +License|/fdl]]."]]"""]] + +[[!tag open_issue_documentation]] + + + +TODO. diff --git a/microkernel/mach/port.mdwn b/microkernel/mach/port.mdwn index 7f02628d..26b55456 100644 --- a/microkernel/mach/port.mdwn +++ b/microkernel/mach/port.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010 Free Software +[[!meta copyright="Copyright © 2002, 2003, 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -10,8 +10,8 @@ is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] [[Mach]] *port*s are [[capabilities|capability]], and are also essentially -similar to [[UNIX]] pipes. They are communication channels, implemented by -kernel queues. +similar to [[UNIX]] pipes. They are unforgeable communication channels, +implemented by kernel queues. Each port has associated with it one *receive right* and one or more *send right*s and *send-once right*s. That is, there is one receiver and one or more @@ -39,7 +39,7 @@ like [[UNIX file descriptors|unix/file_descriptor]]. Only these local names can be used by [[thread]]s for invoking operations on ports, threads do not deal with port rights directly. -For that, each task has associated with it a *port address_space*, or *port +For that, each task has associated with it a *port address space*, or *port name space*. All ports are addressed via this table. Each task thus has its own private [[naming_context]] for port rights. @@ -58,20 +58,24 @@ The delivery of [[message]]s is reliable and strictly ordered. When a intermediate messages that are sent by other threads. Ports are objects that are implemented by the [[kernel]], and they are -kernel-protected resources. There is no way for a [[task]] to do anything with -a port unless it have corresponding port right. +kernel-protected resources: they are unforgeable, and there is no way for a +[[task]] to do anything with a port unless it have corresponding port right. Due to this, ports are globally unique. This makes them ideal for constituting -system-wide *object references*. For example, the [[RPC]] system as used by -the GNU Hurd works by invoking *methods* on such object references. The -available methods are defined in [[hurd/interface]] files, and are processes by -the [[MIG]] tool. +system-wide *object references*. (Fruther reading: +{{$capability#wikipedia_object-capability_model}}.) For example, the [[RPC]] +system as used by the GNU Hurd works by invoking *methods* on such object +references. The available methods are defined in [[hurd/interface]] files, and +are processes by the [[MIG]] tool. Invoking an operation on a port does not transfer the current execution control to the receiver, but instead is an asynchronous operation. For this, and especially in a [[RPC]] system, the sender may include a *reply port* using a send-once right, and synchronize (block) on that one. + +# Port Set + A [[thread]] can only block receiving on a single port. To work around this, the concept of a *port set* was introduced. A receive right can be added to (at most) one port set. These port sets look like port receive rights, but diff --git a/open_issues/multithreading.mdwn b/open_issues/multithreading.mdwn index 4309494d..1fc2c318 100644 --- a/open_issues/multithreading.mdwn +++ b/open_issues/multithreading.mdwn @@ -47,7 +47,8 @@ Tom Van Cutsem, 2009. * [[Erlang-style_parallelism]] - * [[!wikipedia Actor_model]] + * [[!wikipedia Actor_model]]; also see overlap with + {{$capability#wikipedia_object-capability_model}}. * [libtcr - Threaded Coroutine Library](http://oss.linbit.com/libtcr/) diff --git a/persistency.mdwn b/persistency.mdwn index 36f90c8a..d45ebacc 100644 --- a/persistency.mdwn +++ b/persistency.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2007, 2008, 2010 Free Software Foundation, +[[!meta copyright="Copyright © 2007, 2008, 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable @@ -17,3 +17,26 @@ processes and [[capabilities|capability]] also survive reboot. To a process, it generally only looks as if it had not been scheduled for a long time; the rest of its environment remains essentially the indistinguishable. + + +# GNU/Hurd + +The GNU/Hurd is not a persistent system: there are no persistent +[[capabilities|capability]]. All data that is stored in files in the file +system, is serialized. + + +# Further Reading + +[[!toggleable id=shapiro_capintro_1999 text="""[[!template id=note +text="*[[shapiro\_capintro\_1999|capability]]*: +{{$capability#shapiro_capintro_1999}}. +{{$capability#shapiro_capintro_1999_text}}."]]"""]] + + * Section *Writing Things Down* in [[!toggle id=shapiro_capintro_1999 + text="[shapiro\_capintro\_1999]"]]. + + +[[!tag open_issue_documentation]] diff --git a/unix/file_descriptor.mdwn b/unix/file_descriptor.mdwn index 6f8533c5..b40db67f 100644 --- a/unix/file_descriptor.mdwn +++ b/unix/file_descriptor.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2010 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2010, 2011 Free Software Foundation, Inc."]] [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable id="license" text="Permission is granted to copy, distribute and/or modify this @@ -11,6 +11,7 @@ License|/fdl]]."]]"""]] A *file descriptor* is a [[concept]] of [[UNIX]], and represents a non-[[persistent|persistency]] handle to an object (a file, for example). With respect to specific aspects, it is comparable to a [[capability]]. +This is detailed in {{$capability#wikipedia_capability-based_security}}. In a GNU Hurd system, the concept of file descriptors is based on object handles (through [[Mach ports|microkernel/mach/port]]), and is [[implemented in -- cgit v1.2.3