From 40fce0b2c547fe7a73267f5285fb1f596f8ff947 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Mon, 13 Jun 2011 16:44:12 +0200 Subject: open_issues/git_duplicated_content: Progress? --- hurd/translator/ext2fs.mdwn | 16 ++++++++++++---- hurd/translator/ext2fs/filetype.mdwn | 33 +++++++++++++++++++++++++++++++++ 2 files changed, 45 insertions(+), 4 deletions(-) create mode 100644 hurd/translator/ext2fs/filetype.mdwn (limited to 'hurd') diff --git a/hurd/translator/ext2fs.mdwn b/hurd/translator/ext2fs.mdwn index 305576b8..fff2e74b 100644 --- a/hurd/translator/ext2fs.mdwn +++ b/hurd/translator/ext2fs.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 @@ -9,14 +9,20 @@ 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]]."]]"""]] -# Large Stores +# Implementation + + * [[filetype]] option + + +## Large Stores The `ext2fs` translator from the upstream Hurd code base can only handle file systems with sizes of less than roughly 2 GiB. [[!tag open_issue_hurd]] -## Ognyan's Work + +### Ognyan's Work * Ognyan Kulev, [[*Supporting Large ext2 File Systems in the Hurd*|ogi-fosdem2005.mgp]], 2005, at FOSDEM @@ -34,4 +40,6 @@ small backend stores, like floppy devices. # Documentation - + * + + * diff --git a/hurd/translator/ext2fs/filetype.mdwn b/hurd/translator/ext2fs/filetype.mdwn new file mode 100644 index 00000000..5d85bac9 --- /dev/null +++ b/hurd/translator/ext2fs/filetype.mdwn @@ -0,0 +1,33 @@ +[[!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]]."]]"""]] + +The *ext2fs* translator doesn't support the ext2 format's *filetype* option. + +According to *mke2fs(8)*: + +> **filetype**: Store file type information in directory entries. + +By setting directory listings' informational `d_type` field (`readdir`, etc.), +this may avoid the need for subsequent `stat` calls. + +Not all file systems can support this option. + +In `[hurd]/ext2fs/dir.c` the `EXT2_FEATURE_INCOMPAT_FILETYPE` is generally +masked out (is not even considered) when adding a node to a directory in +`diskfs_direnter_hard` and when reading in `diskfs_get_directs`. The Hurd's +ext2fs unconditionally sets this field to 0 (`EXT2_FT_UNKNOWN`). + + +# `e2fsck` + +Running `e2fsck` on a file system with the *filetype* option, will correct the +*filetype* for a lot of files (all `EXT2_FT_UNKNOWN`?) to either 1 (regular +file, `EXT2_FT_REG_FILE`), or 2 (directory, `EXT2_FT_DIR`), and likely others. +The Hurd's ext2fs will again ignore these fields, of course. -- cgit v1.2.3 From a5b95baab6b4512ceaef8749a29ed7b3685b4125 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Wed, 15 Jun 2011 22:54:09 +0200 Subject: Some more bits from IRC and elsewhere. --- hurd/running/qemu/discussion.mdwn | 92 +++++++++++++++++++++++++++++++++ microkernel/mach/gnumach/ports/xen.mdwn | 24 +++++++-- toolchain.mdwn | 8 ++- toolchain/elfosabi_hurd.mdwn | 83 +++++++++++++++++++++++++++++ user/jkoenig/java.mdwn | 5 +- 5 files changed, 204 insertions(+), 8 deletions(-) create mode 100644 toolchain/elfosabi_hurd.mdwn (limited to 'hurd') diff --git a/hurd/running/qemu/discussion.mdwn b/hurd/running/qemu/discussion.mdwn index fd0df4c5..1ce14b01 100644 --- a/hurd/running/qemu/discussion.mdwn +++ b/hurd/running/qemu/discussion.mdwn @@ -50,3 +50,95 @@ The problem is actually that the linux block cache doesn't make any consistency between /dev/hda and /dev/hda6, so if you give /dev/hda to qemu, qemu writings won't be consistent with mounting /dev/hda6 in linux. You can give /dev/hda6 directly to qemu and it will be fine. + + +# Host-side Writeback Caching + +IRC, freenode, #hurd, 2011-06-07 + + hm, i guess i should have used cache=writeback with kvm before + starting the debian installer :/ + ah yes, much better + this shows how poor the state of our I/O drivers and subsystem is + :/ + indeed... still no clustered pageout :-( + and no I/O scheduler either + although an I/O scheduler has limited value without clustered + pageouts + since one of its goals is to pack related I/O requests together eh + i wonder if the wiki mentions using cache=writeback to speed up + qemu performances + it would help those unable to use kvm a lot + and even those running kvm too + kvm -m $RAM \ -monitor stdio \ -drive + cache=writeback,index=0,media=disk,file=hd0.img \ + etc.. + the idea is that qemu doesn't open its disk file synchronously + changes are queued in the host page cache before being flushed to + the disk image + but if you brutally close your qemu instance, you're likely to + loose file system consistency + ext2fs will think it has committed its metadata to the disk, but + the disk image won't be updated synchronously + on my machine (which is quite fast), my kvm has installed debian + like 10 times faster than without the option + braunr: I don't think killing qemu should hurt in this + case... probably only matters when the host machine dies + antrik: ah yes, right + it really makes everything faster, even downloading, since I/O + requests aren't interleaved between networking RPCs + regarding I/O sheduler... this discussion came up before, but I + don't remember the outcome -- doesn't the glued Linux driver actually + come with one? + i don't remember either + braunr: err... I don't think interleaving has anything to do with + it... I guess it's simply the fact that downloading writes the result to + disk, which suffers from lacking clustered pageout like everything else + (my internet connection is too slow though to notice :-) ) + well, if there is no I/O during downloading, downloading is faster + :) + +IRC, freenode, #hurd, 2011-06-08 + + youpi: does xen provide disk caching options ? + through a blktap, probably + ok + +([[microkernel/mach/gnumach/ports/Xen]], *Host-side Writeback Caching*.) + + we should find the pages mentioning qemu on the wiki and add the + options to enable disk image caching + it really makes the hurd run a lot faster + as a workaround for emulators until I/O is reworked, ofc + +IRC, freenode, #hurd, 2011-06-09 + + braunr recommends to use writeback caching with kvm. Is this + really recommended with the frequent crashes I experience? + provided that you terminate your kvm normaly (i.e. quitting it, not + killing it), there should be no difference + I think the host's stability is what matters + the data presumably sits in linux's cache even if qemu dies + violently + But the freezes I see force me to kill kvm :-( + maybe kvm doesn't even do caching indeed, I don't know + gnu_srs: you can quit even when frozen + use the console + (the kvm console) + gnu_srs, "Writeback caching will report data writes as completed + as soon as the data is present in the host page cache. This is safe as + long as you trust your host. If your host crashes or loses power, then + the guest may experience data corruption." (from the qemu manpage) + +IRC, freenode, #hurd, 2011-06-11 + + braunr: If you are online. For me setting the parameters -drive + cache=writeback,index=0,media=disk,file=hd0.img does not show any speed + improvement at all compared to the default. + gnu_srs: what's your complete qemu command line ? + kvm -m 1024 -net nic,model=rtl8139 -net + user,hostfwd=tcp::5556-:22 -drive + cache=writeback,index=0,media=disk,file=hd0.img -cdrom netinst.iso + what qemu version ? + qemu-kvm 0.14.1+dfsg-1: Sorry, I cannot be online until + tomorrow again. diff --git a/microkernel/mach/gnumach/ports/xen.mdwn b/microkernel/mach/gnumach/ports/xen.mdwn index bf26410a..af431c92 100644 --- a/microkernel/mach/gnumach/ports/xen.mdwn +++ b/microkernel/mach/gnumach/ports/xen.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,11 +6,12 @@ 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]]."]]"""]] [[!toc]] + # Xen dom0, hypervisor /!\ Now that GNU Mach handles PAE you can use a PAE-enabled hypervisor. @@ -30,6 +31,7 @@ If you have a free partition, you can fdisk to type 0x83, create a filesystem us Replace /dev/sda4 with your partition. Install and use crosshurd to setup a GNU/Hurd system on this partition. + # /etc/xen/hurd configuration Here is a sample /etc/xen/hurd configuration @@ -49,6 +51,7 @@ Suggestions about [[networking_configuration]] are available. If you need stable MAC addresses, use a syntax like `vif = [ 'mac=00:16:3e:XX:XX:XX, bridge=br0' ]`. + # Running Hurd with Xen To run Hurd with Xen, use: @@ -63,6 +66,7 @@ and gnumach should get started. Proceed with native-install. - If `xm` complains about networking (`vif could not be connected`), it's Xen scripts' fault, see Xen documentation for how to configure the network. The simplest way is network-bridge with fixed IPs (note that you need the bridge-utils package for this). You can also just disable networking by commenting the vif line in the config. - If `xm` complains `Error: (2, 'Invalid kernel', 'xc_dom_compat_check: guest type xen-3.0-x86_32 not supported by xen kernel, sorry\n')`, you most probably have a PAE-enabled hypervisor and a non-PAE gnumach. Either install and boot non-PAE hypervisor and kernel, or rebuilt gnumach in PAE mode. + # Building from sources If you want to generate these images, first get the `gnumach-1-branch-Xen-branch` branch from gnumach CVS. @@ -75,7 +79,6 @@ 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! ---- # Miscellaneous @@ -83,7 +86,6 @@ The current `hurd-modules` was built from the debian packages `hurd 20070606-2` [[!GNU_Savannah_task 5468]], [[!GNU_Savannah_task 6584]]. ---- # `pv-grub` @@ -91,3 +93,15 @@ 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). + + +# Host-side Writeback Caching + +Optimization possible as it is with [[QEMU|hurd/running/qemu/discussion]], +*Host-side Writeback Caching*? + +IRC, freenode, #hurd, 2011-06-08 + + youpi: does xen provide disk caching options ? + through a blktap, probably + ok diff --git a/toolchain.mdwn b/toolchain.mdwn index b08dba95..0059317b 100644 --- a/toolchain.mdwn +++ b/toolchain.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 @@ -24,4 +24,10 @@ for example, how things are done differently for GNU/Hurd than they are done for GNU/Linux. +--- + + * [[ELFOSABI_HURD]] + +--- + * [[cross-gnu]] diff --git a/toolchain/elfosabi_hurd.mdwn b/toolchain/elfosabi_hurd.mdwn new file mode 100644 index 00000000..4d60f761 --- /dev/null +++ b/toolchain/elfosabi_hurd.mdwn @@ -0,0 +1,83 @@ +[[!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="ELFOSABI_HURD"]] + +[[!tag open_issue_binutils open_issue_glibc]] + + +# [[!debbug 630180]] + + +# [[open_issues/binutils]] commit 51b2f560ad035dffad3371093f8e5c80608d196c + +Usage of `ELFOSABI_LINUX`/`STB_GNU_UNIQUE`. Has also been wrong before already +with respect to `STT_GNU_IFUNC`? + + +# IRC + +IRC, freenode, #debian-hurd, 2011-06-11 + + youpi: not that there would be any hope in that, but id you try + asking doko about the gcc miscompiling (wrong elf format) issue? + I didn't + I'm still investigating + maybe it's a binutils change actually + youpi: hm, are you sure it could be binutils? after all, even + some .o files are produced with format gnu/linux, so there's no binutils + involved up to that point of thecompilation yet? + as is + "as", I mean + i see + since it's so unclear, I really prefer to investigate before + bothering doko + youpi: maybe i could be wrong, + in binutils, bfd/elf.c, around lines 9580 + the faulty thing seems to be gnu_unique_object in the source .s + file produced by g++ + that's what that comment (which changed wrt binutils from eg + march) says + seems to concur with my comment above :) + http://paste.debian.net/119542/ ‘¡û extract of diff + ok, that really seems the culprit + starting reportbug + who's the fault then? + binutils + it shouldn't hardcode LINUX + g++ emitting those symbols, or binutil considering them "linux"? + it's a GNU thing, not a Linux thing + ah ok + it's the same dynamic linker actually + youpi: http://sourceware.org/bugzilla/show_bug.cgi?id=10549 + see the reporter :) + heh + youpi: see also gas/config/obj-elf.c:1725 + (another change related to that bug, it seems) + +IRC, freenode, #hurd, 2011-06-15 + + also I still get an "ELF file OS ABI invalid" error with binutils + 2.21.52.20110606-2+hurd.1, is that expected? + tschwinge: oops, the OS ABI invalid is actually due to the file + being marked GNU/Hurd + I guess the linker is simply not aware that it should accept + GNU/Hurd + youpi: So we got to work on glibc'S ld.so to teach it aboput + the Hurd OS ABI? (Or probably simply make that equivalent to the Linux + one?) + probably simply an equivalent + ELFOSABI_HURD is missing from elf/elf.h, for a start... + linux' glibc has tests in lsdodefs.h + the VALID_ELF_OSABI macro + it's thus apparently a matter of providing an ldsodefs.h file with + VALID_ELF_HEADER, VALID_ELF_OSABI and VALID_ELF_ABIVERSION definitions + (and include_next the generic one) + I've prepared a patch for ldsodefs.h, I'll test it diff --git a/user/jkoenig/java.mdwn b/user/jkoenig/java.mdwn index 6aeef9fe..8e1fb097 100644 --- a/user/jkoenig/java.mdwn +++ b/user/jkoenig/java.mdwn @@ -140,7 +140,7 @@ by building on [[pochu]]'s `file_exec_file_name()` I have succeeded in building a Hotspot-enabled `libjvm.so`, although the current toolchain issues -(*Hurd OS ABI*) +([[toolchain/ELFOSABI_HURD]]) have so far prevented me from testing it. @@ -151,7 +151,8 @@ have so far prevented me from testing it. * Assuming it is, continue with getting `$ORIGIN` working. - * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: *Hurd OS ABI*. + * [!] [[Samuel|samuelthibault]]/[[tschwinge]]/[[jkoenig]]: + [[toolchain/ELFOSABI_HURD]]. * They seem to have a rather heavy-weight process for such projects: confer , -- cgit v1.2.3 From 650af65a812e353c16454cc3a4d72953b867c17b Mon Sep 17 00:00:00 2001 From: "https://www.google.com/accounts/o8/id?id=AItOawn-2YjCU2PbH_m8JGSbjoN01lFbJc5k0YY" Date: Sun, 26 Jun 2011 03:13:28 +0200 Subject: --- hurd/flashhurd.mdwn | 24 ++++++++++++++++++++++++ 1 file changed, 24 insertions(+) create mode 100644 hurd/flashhurd.mdwn (limited to 'hurd') diff --git a/hurd/flashhurd.mdwn b/hurd/flashhurd.mdwn new file mode 100644 index 00000000..68669f84 --- /dev/null +++ b/hurd/flashhurd.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]]."]]"""]] + +HERE STARTS YOUR NEW CONTENT -- remove everything from here on, including this +line. + +By creating this page, you agree to assign copyright for your contribution to +the Free Software Foundation, . The Free Software +Foundation promises to always use a free documentation license (as per our +criteria of free documentation) when publishing your contribution. We grant +you back all your rights under copyright, including the rights to copy, modify, +and redistribute your contributions. + +We're requiring these copyright assignments, so that we'll easily be able to +include your contributions in official GNU documentation, such as the GNU Hurd +Reference Manual, etc. Send email to if there are +questions. -- cgit v1.2.3 From 19129dac9b9e558b501d8a01536e7c3efbf01ef8 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sun, 3 Jul 2011 17:01:51 +0200 Subject: Remove empty page. This reverts commit 650af65a812e353c16454cc3a4d72953b867c17b. --- hurd/flashhurd.mdwn | 24 ------------------------ hurd/running.mdwn | 1 - 2 files changed, 25 deletions(-) delete mode 100644 hurd/flashhurd.mdwn (limited to 'hurd') diff --git a/hurd/flashhurd.mdwn b/hurd/flashhurd.mdwn deleted file mode 100644 index 68669f84..00000000 --- a/hurd/flashhurd.mdwn +++ /dev/null @@ -1,24 +0,0 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] - -[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable -id="license" text="Permission is granted to copy, distribute and/or modify this -document under the terms of the GNU Free Documentation License, Version 1.2 or -any later version published by the Free Software Foundation; with no Invariant -Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license -is included in the section entitled [[GNU Free Documentation -License|/fdl]]."]]"""]] - -HERE STARTS YOUR NEW CONTENT -- remove everything from here on, including this -line. - -By creating this page, you agree to assign copyright for your contribution to -the Free Software Foundation, . The Free Software -Foundation promises to always use a free documentation license (as per our -criteria of free documentation) when publishing your contribution. We grant -you back all your rights under copyright, including the rights to copy, modify, -and redistribute your contributions. - -We're requiring these copyright assignments, so that we'll easily be able to -include your contributions in official GNU documentation, such as the GNU Hurd -Reference Manual, etc. Send email to if there are -questions. diff --git a/hurd/running.mdwn b/hurd/running.mdwn index a51b40cf..b9b50fc0 100644 --- a/hurd/running.mdwn +++ b/hurd/running.mdwn @@ -17,7 +17,6 @@ There are several different ways to run a GNU/Hurd system: * [[QEMU]] - In QEMU * [[VirtualBox]] - In VirtualBox * [[vmware]] (**non-free!**) -* [[FlashHurd]] - From a flash stick * [[FAQ]] -- cgit v1.2.3 From 321b29458db1fd7fd7e63e652d3c93622750155b Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 10 Jun 2011 22:43:24 +0200 Subject: dde/guide: add intro --- hurd/dde/guide.mdwn | 14 +++++++++++++- 1 file changed, 13 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 56f7683c..ffff601d 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.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,6 +8,18 @@ Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled [[GNU Free Documentation License|/fdl]]."]]"""]] +This guide explains how to build and set up +a DDE-based network card driver +with Debian GNU/Hurd, +if your (wired) network card +is not supported by the old in-kernel drivers shipped with gnumach. + +This guide assumes that you have +an installation of Debian GNU/Linux on the same machine, +which helps in fetching the required packages +in absence of working networking in the Hurd. +The whole process is much more cumbersome otherwise. + If you haven't: install hurd to partition get grub image boot hurd in single user (change grub entry accordingly to the installed partition) -- cgit v1.2.3 From 05ae27c5a7a0ec2131444d5d295f7f5c1c2c7a1f Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 10 Jun 2011 22:47:12 +0200 Subject: dde/guide: Drop section about installing Hurd It's really out of place here. Add a note in the intro. --- hurd/dde/guide.mdwn | 12 +++--------- 1 file changed, 3 insertions(+), 9 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index ffff601d..76515dc7 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -19,16 +19,10 @@ an installation of Debian GNU/Linux on the same machine, which helps in fetching the required packages in absence of working networking in the Hurd. The whole process is much more cumbersome otherwise. +It also assumes that apart from networking, +your Hurd system is already installed and operational. -If you haven't: install hurd to partition -get grub image -boot hurd in single user (change grub entry accordingly to the installed partition) - -> $ export TERM=mach - -> $ ./native-install - -reboot to other debian +Start by booting into Debian GNU/Linux for some preparations: suppose hurd partition is hdd1 -- cgit v1.2.3 From eb6338481fca495448aaa7f84d52961e864ab04e Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 10 Jun 2011 23:40:08 +0200 Subject: dde/guide: Drop section about resolv.conf Again, not the right place for this. --- hurd/dde/guide.mdwn | 4 ---- 1 file changed, 4 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 76515dc7..39390add 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -152,8 +152,4 @@ reboot to hurd with the new gnumach_dde replace the ip, gateway and mask with your own ones -> $ nano /etc/resolv.conf - -add line: nameserver 192.168.1.254 - DONE -- cgit v1.2.3 From 5e4d2daf11d94a68d37899f6a62ab10f83867f80 Mon Sep 17 00:00:00 2001 From: antrik Date: Fri, 10 Jun 2011 23:49:23 +0200 Subject: dde/guide: Rewrite comments for clarity --- hurd/dde/guide.mdwn | 62 +++++++++++++++++++++++++++++++++++++++-------------- 1 file changed, 46 insertions(+), 16 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 39390add..f67817fb 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -22,13 +22,12 @@ The whole process is much more cumbersome otherwise. It also assumes that apart from networking, your Hurd system is already installed and operational. -Start by booting into Debian GNU/Linux for some preparations: -suppose hurd partition is hdd1 +Start by booting into Debian GNU/Linux for some preparations: -as root +(as root) -> $ mount /dev/hdd1 /mnt -t ext2 +> $ mount /dev/hdd1 /mnt -t ext2 # assuming your Hurd partition is hdd1 -- replace with whatever matches your setup > $ cd /mnt/etc/apt @@ -61,12 +60,27 @@ as root > $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers gnumach_dde -suppose you need forcedeth driver +Now you need to get the actual driver from the Linux source tree. +You have to find out which Linux driver +is responsible for your network card, +and which source file corresponds to this driver. +In this guide we will use the forcedeth driver +(for Nvidia nForce chipsets) as example. + +Download http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=blob_plain;f=drivers/net/forcedeth.c;hb=HEAD +and save under the file name forcedeth.c in /mnt/home + +(Note: the download from the Git URL above +doesn't work with wget +or other simple user agents without JavaScript. +You will need to use Firefox or some such... +Or figure out a better URL to get the file directly :-) ) -Download http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=blob_plain;f=drivers/net/forcedeth.c;hb=HEAD from mozilla like -browser to /mnt/home as forcedeth.c -reboot back to hurd (multiuser) +Now everything should be in place, +so we can boot into Hurd to do the actual work: + +(again as root) > $ apt-get update @@ -79,6 +93,8 @@ reboot back to hurd (multiuser) > $ apt-get install build-essential libpciaccess-dev libpcap0.8-dev +(this part can be done as normal user) + > $ cd /home/gnumach_dde > $ autoreconf -i && ./configure --enable-kdb --enable-device-drivers=none --enable-lpr --enable-floppy --enable-ide @@ -103,9 +119,7 @@ reboot back to hurd (multiuser) > $ sed -i 's:-I/include:-I..:' Makefile -> $ nano forcedeth.c - -add this line after the last #include +> $ nano forcedeth.c # Near the top of the file, there will be many #include lines. After the last one, add this: #include @@ -131,6 +145,8 @@ add this line after the last #include If the make fails it might be necassary to replace some of the -l options (or all) in Makefile with the real path to the library objects (example: change *-lhurd-slab* to *../libhurd-slab/libhurd-slab.a*) +(as root) + > $ cp /home/gnumach_dde/gnumach /boot/gnumach_dde > $ mkdir /hurd/dde @@ -141,15 +157,29 @@ If the make fails it might be necassary to replace some of the -l options (or al > $ cp /home/hurd_dde/dde_forcedeth/dde_forcedeth /hurd/dde/forcedeth -reboot to hurd with the new gnumach_dde + +Now everything should be built. +Before we can use the driver, +we have to boot with the newly built gnumach_dde +instead of the standard kernel. +(Adapt your grub configuration; +or manually edit the entry +in the boottime grub menu while testing.) +Once there, set up the translators for the driver: + +(as root) > $ settrans -c /dev/forcedeth /hurd/dde/forcedeth > $ settrans -c /dev/eth0 /hurd/dde/devnode -M /dev/forcedeth eth0 -> $ settrans -c /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 -a 192.168.1.194 -g 192.168.1.254 -m 255.255.255.0 - +Finally, we can set up the actual network translator, +using something like: -replace the ip, gateway and mask with your own ones +> $ settrans -c /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 -a 192.168.1.194 -g 192.168.1.254 -m 255.255.255.0 -DONE +For the exact syntax, +see the normal network setup documentation. +The only differences here +are the different location of the pfinet binary, +and the different syntax for the -i option. -- cgit v1.2.3 From ec7b41aca85ba0e3d326ce8796f321e5a169086f Mon Sep 17 00:00:00 2001 From: antrik Date: Sat, 11 Jun 2011 10:47:49 +0200 Subject: dde/guide: Better way to download driver file --- hurd/dde/guide.mdwn | 12 +++++------- 1 file changed, 5 insertions(+), 7 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index f67817fb..e3fcf2e5 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -67,15 +67,13 @@ and which source file corresponds to this driver. In this guide we will use the forcedeth driver (for Nvidia nForce chipsets) as example. -Download http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=blob_plain;f=drivers/net/forcedeth.c;hb=HEAD -and save under the file name forcedeth.c in /mnt/home +Point a (JavaScript-capable) web browser at -(Note: the download from the Git URL above -doesn't work with wget -or other simple user agents without JavaScript. -You will need to use Firefox or some such... -Or figure out a better URL to get the file directly :-) ) +> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tree;f=drivers/net;hb=HEAD +Find the right file to download (e.g. forcedeth.c), +hit the "raw" link, +and save the resulting file (page) to /mnt/home Now everything should be in place, so we can boot into Hurd to do the actual work: -- cgit v1.2.3 From 4db957304bb6d882933617ec70b38d80758df1e3 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 6 Jul 2011 08:38:24 +0200 Subject: dde/guide: Drop "apt-get upgrade" This has nothing to do with DDE; and I don't see why it would be necessary here -- the DDE stuff doesn't need any recent packages to build AFAIK. --- hurd/dde/guide.mdwn | 4 ---- 1 file changed, 4 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index e3fcf2e5..f275c9d7 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -45,8 +45,6 @@ Start by booting into Debian GNU/Linux for some preparations: > $ apt-get -c etc/apt/apt.conf.offline update -> $ apt-get -c etc/apt/apt.conf.offline upgrade - > $ apt-get -c etc/apt/apt.conf.offline install git-core > $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach @@ -82,8 +80,6 @@ so we can boot into Hurd to do the actual work: > $ apt-get update -> $ apt-get upgrade - > $ apt-get install git-core > $ apt-get build-dep hurd gnumach -- cgit v1.2.3 From b4495b7195d2d794b89c6150194a09eea32fc559 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 6 Jul 2011 08:50:16 +0200 Subject: dde/guide: Drop "apt-get update" in Hurd I'm pretty sure it is neither possible nor necessary with the apt offline setup. --- hurd/dde/guide.mdwn | 2 -- 1 file changed, 2 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index f275c9d7..74962222 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -78,8 +78,6 @@ so we can boot into Hurd to do the actual work: (again as root) -> $ apt-get update - > $ apt-get install git-core > $ apt-get build-dep hurd gnumach -- cgit v1.2.3 From ff99222cc9af6b4f52e5af909f9b3bd8b598d7c2 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 6 Jul 2011 08:53:49 +0200 Subject: dde/guide: Merge install command for git-core with other packages --- hurd/dde/guide.mdwn | 8 ++------ 1 file changed, 2 insertions(+), 6 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 74962222..d6dffb85 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -45,11 +45,9 @@ Start by booting into Debian GNU/Linux for some preparations: > $ apt-get -c etc/apt/apt.conf.offline update -> $ apt-get -c etc/apt/apt.conf.offline install git-core - > $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach -> $ apt-get -c etc/apt/apt.conf.offline install build-essential libpciaccess-dev libpcap0.8-dev +> $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev > $ cd /mnt/home @@ -78,11 +76,9 @@ so we can boot into Hurd to do the actual work: (again as root) -> $ apt-get install git-core - > $ apt-get build-dep hurd gnumach -> $ apt-get install build-essential libpciaccess-dev libpcap0.8-dev +> $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev (this part can be done as normal user) -- cgit v1.2.3 From 8874ec5fa546ccd5132a30d64dd5364ab6b0b529 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 6 Jul 2011 09:58:03 +0200 Subject: dde/guide: Add many more explanations --- hurd/dde/guide.mdwn | 60 +++++++++++++++++++++++++++++++++-------------------- 1 file changed, 37 insertions(+), 23 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index d6dffb85..1418638c 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -23,15 +23,18 @@ It also assumes that apart from networking, your Hurd system is already installed and operational. -Start by booting into Debian GNU/Linux for some preparations: +We start by booting into Debian GNU/Linux, +so we can downloading everything we will need for building DDE. -(as root) +Once there, first mount the Hurd partition (as root): > $ mount /dev/hdd1 /mnt -t ext2 # assuming your Hurd partition is hdd1 -- replace with whatever matches your setup +Prepare apt offline configuration so we can get necessary packages: + > $ cd /mnt/etc/apt -> $ echo "deb http://ftp.debian-ports.org/debian unreleased main" >> sources.list +> $ echo "deb http://ftp.debian-ports.org/debian unreleased main" >> sources.list # if you don't have sources.list set up yet on the Hurd system > $ echo "deb-src http://ftp.debian-ports.org/debian unreleased main" >> sources.list @@ -41,6 +44,8 @@ Start by booting into Debian GNU/Linux for some preparations: > $ wget http://www.gnu.org/software/hurd/hurd/running/debian/DebianAptOffline/apt.conf.offline +Download the packages for offline installation: + > $ cd /mnt > $ apt-get -c etc/apt/apt.conf.offline update @@ -49,13 +54,14 @@ Start by booting into Debian GNU/Linux for some preparations: > $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev +Get DDE code: + > $ cd /mnt/home > $ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd_dde > $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers gnumach_dde - Now you need to get the actual driver from the Linux source tree. You have to find out which Linux driver is responsible for your network card, @@ -71,17 +77,17 @@ Find the right file to download (e.g. forcedeth.c), hit the "raw" link, and save the resulting file (page) to /mnt/home + Now everything should be in place, -so we can boot into Hurd to do the actual work: +so we can boot into Hurd to do the actual work. -(again as root) +Once there, install the packages previously downloaded (again as root): > $ apt-get build-dep hurd gnumach > $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev - -(this part can be done as normal user) +Build a DDE-enabled Mach (this and following parts can be done as normal user): > $ cd /home/gnumach_dde @@ -89,23 +95,25 @@ so we can boot into Hurd to do the actual work: > $ make +Prepare the driver for your network card: + > $ cd ../hurd_dde -> $ cp -r dde_pcnet32 dde_forcedeth +> $ cp -r dde_pcnet32 dde_forcedeth # using pcnet32 as template > $ cd dde_forcedeth -> $ rm pcnet32.c +> $ rm pcnet32.c # don't want the actual pcnet32 code here... -> $ cp /home/forcedeth.c ./ +> $ cp /home/forcedeth.c ./ # ...but rather the forcedeth code -> $ sed -i 's/pcnet32/forcedeth/g' Makefile +> $ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly > $ sed -i 's/pcnet32/forcedeth/g' .gitignore -> $ sed -i 's:-lhurd-slab:../libhurd-slab/libhurd-slab.a:' Makefile +> $ sed -i 's:-lhurd-slab:../libhurd-slab/libhurd-slab.a:' Makefile # fix up build system... XXX I guess this part is obsolete -> $ sed -i 's:-I/include:-I..:' Makefile +> $ sed -i 's:-I/include:-I..:' Makefile # same > $ nano forcedeth.c # Near the top of the file, there will be many #include lines. After the last one, add this: @@ -113,27 +121,34 @@ so we can boot into Hurd to do the actual work: > $ cd .. +Commit the driver with git. +This will be helpful if we update the DDE code later; +as well as for creating a patch for later reuse +and/or upstream submission: + > $ git add dde_forcedeth > $ git commit -a -m 'Add forcedeth driver' +Build the necessary Hurd and DDE bits: + > $ autoreconf -i && ./configure -> $ mkdir -p hurd/include/ddekit +> $ mkdir -p hurd/include/ddekit # workaround for a buildsystem bug... XXX I'm pretty sure this is not necessary anymore -> $ make libddekit libmachdev devnode pfinet +> $ make libddekit libmachdev devnode pfinet # Hurd components -> $ cd libdde_linux26 +> $ cd libdde_linux26 # common DDE driver code -- uses a different Makefile system than the Hurd components! > $ make -> $ cd ../dde_forcedeth +> $ cd ../dde_forcedeth # actual driver > $ make -If the make fails it might be necassary to replace some of the -l options (or all) in Makefile with the real path to the library objects (example: change *-lhurd-slab* to *../libhurd-slab/libhurd-slab.a*) +If the make fails it might be necassary to replace some of the -l options (or all) in Makefile with the real path to the library objects (example: change *-lhurd-slab* to *../libhurd-slab/libhurd-slab.a*) XXX -(as root) +Install the various built components to their final destinations (as root): > $ cp /home/gnumach_dde/gnumach /boot/gnumach_dde @@ -146,16 +161,15 @@ If the make fails it might be necassary to replace some of the -l options (or al > $ cp /home/hurd_dde/dde_forcedeth/dde_forcedeth /hurd/dde/forcedeth -Now everything should be built. +Now everything should be ready. Before we can use the driver, we have to boot with the newly built gnumach_dde instead of the standard kernel. (Adapt your grub configuration; or manually edit the entry in the boottime grub menu while testing.) -Once there, set up the translators for the driver: -(as root) +Once there, set up the translators for the driver (as root): > $ settrans -c /dev/forcedeth /hurd/dde/forcedeth -- cgit v1.2.3 From 425b9fc977ff09b9fd8a10eaaa5406f6bc329c67 Mon Sep 17 00:00:00 2001 From: antrik Date: Wed, 6 Jul 2011 11:03:02 +0200 Subject: dde/guide: Be clearer about requirement for creating new driver Explain that it is only necessary to create a new driver if an appropriate one isn't in DDE already; and mention which steps are necessary only in this case. Also be explicit about the fact that this guide only deals with single-file drivers. --- hurd/dde/guide.mdwn | 37 ++++++++++++++++++++++++++++--------- 1 file changed, 28 insertions(+), 9 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 1418638c..c4ff1772 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -62,21 +62,36 @@ Get DDE code: > $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers gnumach_dde -Now you need to get the actual driver from the Linux source tree. -You have to find out which Linux driver -is responsible for your network card, -and which source file corresponds to this driver. +Now comes the tricky part: +you need to find out +whether there is already a driver for your card +in the DDE source tree, +and otherwise get the driver code +from the official Linux source tree. + +For this, you have to find out which Linux driver +is responsible for your network card. In this guide we will use the forcedeth driver (for Nvidia nForce chipsets) as example. +We check whether there is already a `dde_forcedeth` directory +in the newly cloned `hurd_dde` tree. +If there isn't, we have to find and download +the right source file from Linux: Point a (JavaScript-capable) web browser at > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tree;f=drivers/net;hb=HEAD -Find the right file to download (e.g. forcedeth.c), -hit the "raw" link, +Find the right file to download +(forcedeth.c in this example); +then hit the "raw" link, and save the resulting file (page) to /mnt/home +(If you happen to need one of the few drivers +that consist of more than one source file, +the process will be more complicated, +and can't be covered in this guide...) + Now everything should be in place, so we can boot into Hurd to do the actual work. @@ -95,7 +110,9 @@ Build a DDE-enabled Mach (this and following parts can be done as normal user): > $ make -Prepare the driver for your network card: + +If not already present in DDE, +we need to prepare the driver for the network card: > $ cd ../hurd_dde @@ -121,7 +138,7 @@ Prepare the driver for your network card: > $ cd .. -Commit the driver with git. +Commit the new driver with git. This will be helpful if we update the DDE code later; as well as for creating a patch for later reuse and/or upstream submission: @@ -130,7 +147,9 @@ and/or upstream submission: > $ git commit -a -m 'Add forcedeth driver' -Build the necessary Hurd and DDE bits: + +Having prepared the driver, +we can now build the necessary Hurd and DDE bits: > $ autoreconf -i && ./configure -- cgit v1.2.3 From 94fab8bd64b2f1821b5f15b137086d51c42bac8d Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 09:10:05 +0200 Subject: dde/guide: Don't abuse /home/ Put stuff in an actual user home directory, rather than stuffing it directly in /home/ --- hurd/dde/guide.mdwn | 26 +++++++++++++++----------- 1 file changed, 15 insertions(+), 11 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index c4ff1772..4f455790 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -56,11 +56,13 @@ Download the packages for offline installation: Get DDE code: -> $ cd /mnt/home +> $ cd /mnt/home/me # assuming your user name on the Hurd system is "me" -> $ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd_dde +> $ mkdir dde && cd dde -> $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers gnumach_dde +> $ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd + +> $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers Now comes the tricky part: you need to find out @@ -85,7 +87,7 @@ Point a (JavaScript-capable) web browser at Find the right file to download (forcedeth.c in this example); then hit the "raw" link, -and save the resulting file (page) to /mnt/home +and save the resulting file (page) to /mnt/home/me/dde (If you happen to need one of the few drivers that consist of more than one source file, @@ -104,7 +106,7 @@ Once there, install the packages previously downloaded (again as root): Build a DDE-enabled Mach (this and following parts can be done as normal user): -> $ cd /home/gnumach_dde +> $ cd ~me/dde/gnumach > $ autoreconf -i && ./configure --enable-kdb --enable-device-drivers=none --enable-lpr --enable-floppy --enable-ide @@ -114,7 +116,7 @@ Build a DDE-enabled Mach (this and following parts can be done as normal user): If not already present in DDE, we need to prepare the driver for the network card: -> $ cd ../hurd_dde +> $ cd ~me/dde/hurd > $ cp -r dde_pcnet32 dde_forcedeth # using pcnet32 as template @@ -122,7 +124,7 @@ we need to prepare the driver for the network card: > $ rm pcnet32.c # don't want the actual pcnet32 code here... -> $ cp /home/forcedeth.c ./ # ...but rather the forcedeth code +> $ cp ~me/dde/forcedeth.c ./ # ...but rather the forcedeth code > $ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly @@ -169,15 +171,17 @@ If the make fails it might be necassary to replace some of the -l options (or al Install the various built components to their final destinations (as root): -> $ cp /home/gnumach_dde/gnumach /boot/gnumach_dde +> $ cd ~me/dde/ + +> $ cp gnumach/gnumach /boot/gnumach_dde > $ mkdir /hurd/dde -> $ cp /home/hurd_dde/devnode/devnode /hurd/dde +> $ cp hurd/devnode/devnode /hurd/dde -> $ cp /home/hurd_dde/pfinet/pfinet /hurd/dde +> $ cp hurd/pfinet/pfinet /hurd/dde -> $ cp /home/hurd_dde/dde_forcedeth/dde_forcedeth /hurd/dde/forcedeth +> $ cp hurd/dde_forcedeth/dde_forcedeth /hurd/dde/forcedeth Now everything should be ready. -- cgit v1.2.3 From 88537e912dff92178e0b1da744f2f63fc7925e12 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 09:34:26 +0200 Subject: dde/guide: Be more explicit about building as user Instead of just vaguely stating that things can be done as user, explicitely suggest logging in as user. More importantly, include the chown command necessary for this actually to work... --- hurd/dde/guide.mdwn | 8 +++++++- 1 file changed, 7 insertions(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 4f455790..16c248ae 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -104,7 +104,13 @@ Once there, install the packages previously downloaded (again as root): > $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev -Build a DDE-enabled Mach (this and following parts can be done as normal user): +Make sure we can build stuff as normal user: + +> $ chown -R me ~me/dde + +Now you can log in with the normal user account to build stuff. + +Build a DDE-enabled Mach: > $ cd ~me/dde/gnumach -- cgit v1.2.3 From 81cd1343c95216ddc3086656f87b29707c18af86 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 09:37:31 +0200 Subject: dde/guide: Drop unnecessary trailing slash Explicitely using "./" instead of just "." is necessary only in some very special situations... This in not one of them. So use the simpler and more familiar form. --- hurd/dde/guide.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 16c248ae..4264f7ad 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -130,7 +130,7 @@ we need to prepare the driver for the network card: > $ rm pcnet32.c # don't want the actual pcnet32 code here... -> $ cp ~me/dde/forcedeth.c ./ # ...but rather the forcedeth code +> $ cp ~me/dde/forcedeth.c . # ...but rather the forcedeth code > $ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly -- cgit v1.2.3 From 699f4c1a555bed70f8890ce7461e7422ca116db4 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 10:18:31 +0200 Subject: dde/guide: Don't rename driver binary upon install I don't see any use in that; it only creates potential confusion and other problems. --- hurd/dde/guide.mdwn | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 4264f7ad..10a2b727 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -187,7 +187,7 @@ Install the various built components to their final destinations (as root): > $ cp hurd/pfinet/pfinet /hurd/dde -> $ cp hurd/dde_forcedeth/dde_forcedeth /hurd/dde/forcedeth +> $ cp hurd/dde_forcedeth/dde_forcedeth /hurd/dde Now everything should be ready. -- cgit v1.2.3 From 00f52298039e1db2f469834fb9f8c31d6e022faa Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 10:20:49 +0200 Subject: dde/guide: Install all Hurd bits in one "cp" command --- hurd/dde/guide.mdwn | 6 +----- 1 file changed, 1 insertion(+), 5 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 10a2b727..89422625 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -183,11 +183,7 @@ Install the various built components to their final destinations (as root): > $ mkdir /hurd/dde -> $ cp hurd/devnode/devnode /hurd/dde - -> $ cp hurd/pfinet/pfinet /hurd/dde - -> $ cp hurd/dde_forcedeth/dde_forcedeth /hurd/dde +> $ cp hurd/devnode/devnode hurd/pfinet/pfinet hurd/dde_forcedeth/dde_forcedeth /hurd/dde Now everything should be ready. -- cgit v1.2.3 From 04a7d787d0372ee1406ff626826ffc7f8a336cd3 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 10:38:57 +0200 Subject: dde/guide: Add note about Linux version --- hurd/dde/guide.mdwn | 3 +++ 1 file changed, 3 insertions(+) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index 89422625..eeb25ae1 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -84,6 +84,9 @@ Point a (JavaScript-capable) web browser at > http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tree;f=drivers/net;hb=HEAD +(Note: you **have** to use 2.6.29, +as this is the version DDE is currently based on.) + Find the right file to download (forcedeth.c in this example); then hit the "raw" link, -- cgit v1.2.3 From 22fd6914758fe7f049fe39b71297a0874b8d6150 Mon Sep 17 00:00:00 2001 From: antrik Date: Thu, 7 Jul 2011 10:45:13 +0200 Subject: dde/guide: Drop extra note about possibly necessary Makefile changes Even if it should turn out this is not completely obsolete (which I'm pretty sure it is), the specific cases are already covered in the instructions; and if any new should pop up, the guide needs to be updated accordingly. Making the user guess just doesn't fit with such a step-by-step guide. --- hurd/dde/guide.mdwn | 2 -- 1 file changed, 2 deletions(-) (limited to 'hurd') diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn index eeb25ae1..e3588335 100644 --- a/hurd/dde/guide.mdwn +++ b/hurd/dde/guide.mdwn @@ -176,8 +176,6 @@ we can now build the necessary Hurd and DDE bits: > $ make -If the make fails it might be necassary to replace some of the -l options (or all) in Makefile with the real path to the library objects (example: change *-lhurd-slab* to *../libhurd-slab/libhurd-slab.a*) XXX - Install the various built components to their final destinations (as root): > $ cd ~me/dde/ -- cgit v1.2.3 From a8e3de8d7b9237e69346fcf44010a41d5da08c8e Mon Sep 17 00:00:00 2001 From: antrik Date: Sat, 9 Jul 2011 12:41:54 +0200 Subject: dde/guide: Use tabs instead of quote marks This way we lose the indentation -- but special characters are escaped automatically. Also, the commands appear in monospace font (as 
blocks) this way, which I think is better.

There might be some prettier option -- but I'm too lazy to check :-) The
formatting of the whole thing is not exactly good anyways...
---
 hurd/dde/guide.mdwn | 98 ++++++++++++++++++++++++++---------------------------
 1 file changed, 49 insertions(+), 49 deletions(-)

(limited to 'hurd')

diff --git a/hurd/dde/guide.mdwn b/hurd/dde/guide.mdwn
index e3588335..31671308 100644
--- a/hurd/dde/guide.mdwn
+++ b/hurd/dde/guide.mdwn
@@ -28,41 +28,41 @@ so we can downloading everything we will need for building DDE.
 
 Once there, first mount the Hurd partition (as root):
 
-> $ mount /dev/hdd1 /mnt -t ext2 # assuming your Hurd partition is hdd1 -- replace with whatever matches your setup
+	$ mount /dev/hdd1 /mnt -t ext2 # assuming your Hurd partition is hdd1 -- replace with whatever matches your setup
 
 Prepare apt offline configuration so we can get necessary packages:
 
-> $ cd /mnt/etc/apt
+	$ cd /mnt/etc/apt
 
-> $ echo "deb http://ftp.debian-ports.org/debian unreleased main" >> sources.list # if you don't have sources.list set up yet on the Hurd system
+	$ echo "deb http://ftp.debian-ports.org/debian unreleased main" >> sources.list # if you don't have sources.list set up yet on the Hurd system
 
-> $ echo "deb-src http://ftp.debian-ports.org/debian unreleased main" >> sources.list
+	$ echo "deb-src http://ftp.debian-ports.org/debian unreleased main" >> sources.list
 
-> $ echo "deb http://ftp.uk.debian.org/debian unstable main" >> sources.list
+	$ echo "deb http://ftp.uk.debian.org/debian unstable main" >> sources.list
 
-> $ echo "deb-src http://ftp.uk.debian.org/debian unstable main" >> sources.list
+	$ echo "deb-src http://ftp.uk.debian.org/debian unstable main" >> sources.list
 
-> $ wget http://www.gnu.org/software/hurd/hurd/running/debian/DebianAptOffline/apt.conf.offline
+	$ wget http://www.gnu.org/software/hurd/hurd/running/debian/DebianAptOffline/apt.conf.offline
 
 Download the packages for offline installation:
 
-> $ cd /mnt
+	$ cd /mnt
 
-> $ apt-get -c etc/apt/apt.conf.offline update
+	$ apt-get -c etc/apt/apt.conf.offline update
 
-> $ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach
+	$ apt-get -c etc/apt/apt.conf.offline build-dep hurd gnumach
 
-> $ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev
+	$ apt-get -c etc/apt/apt.conf.offline install git-core build-essential libpciaccess-dev libpcap0.8-dev
 
 Get DDE code:
 
-> $ cd /mnt/home/me # assuming your user name on the Hurd system is "me"
+	$ cd /mnt/home/me # assuming your user name on the Hurd system is "me"
 
-> $ mkdir dde && cd dde
+	$ mkdir dde && cd dde
 
-> $ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd
+	$ git clone git://git.sv.gnu.org/hurd/incubator.git -b dde hurd
 
-> $ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers
+	$ git clone git://git.sv.gnu.org/hurd/gnumach.git -b master-user_level_drivers
 
 Now comes the tricky part:
 you need to find out
@@ -82,7 +82,7 @@ the right source file from Linux:
 
 Point a (JavaScript-capable) web browser at
 
-> http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tree;f=drivers/net;hb=HEAD
+	http://git.kernel.org/?p=linux/kernel/git/stable/linux-2.6.29.y.git;a=tree;f=drivers/net;hb=HEAD
 
 (Note: you **have** to use 2.6.29,
 as this is the version DDE is currently based on.)
@@ -103,88 +103,88 @@ so we can boot into Hurd to do the actual work.
 
 Once there, install the packages previously downloaded (again as root):
 
-> $ apt-get build-dep hurd gnumach
+	$ apt-get build-dep hurd gnumach
 
-> $ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev
+	$ apt-get install git-core build-essential libpciaccess-dev libpcap0.8-dev
 
 Make sure we can build stuff as normal user:
 
-> $ chown -R me ~me/dde
+	$ chown -R me ~me/dde
 
 Now you can log in with the normal user account to build stuff.
 
 Build a DDE-enabled Mach:
 
-> $ cd ~me/dde/gnumach
+	$ cd ~me/dde/gnumach
 
-> $ autoreconf -i && ./configure --enable-kdb --enable-device-drivers=none --enable-lpr --enable-floppy --enable-ide
+	$ autoreconf -i && ./configure --enable-kdb --enable-device-drivers=none --enable-lpr --enable-floppy --enable-ide
 
-> $ make
+	$ make
 
 
 If not already present in DDE,
 we need to prepare the driver for the network card:
 
-> $ cd ~me/dde/hurd
+	$ cd ~me/dde/hurd
 
-> $ cp -r dde_pcnet32 dde_forcedeth # using pcnet32 as template
+	$ cp -r dde_pcnet32 dde_forcedeth # using pcnet32 as template
 
-> $ cd dde_forcedeth
+	$ cd dde_forcedeth
 
-> $ rm pcnet32.c # don't want the actual pcnet32 code here...
+	$ rm pcnet32.c # don't want the actual pcnet32 code here...
 
-> $ cp ~me/dde/forcedeth.c . # ...but rather the forcedeth code
+	$ cp ~me/dde/forcedeth.c . # ...but rather the forcedeth code
 
-> $ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly
+	$ sed -i 's/pcnet32/forcedeth/g' Makefile # adapt Makefile accordingly
 
-> $ sed -i 's/pcnet32/forcedeth/g' .gitignore
+	$ sed -i 's/pcnet32/forcedeth/g' .gitignore
 
-> $ sed -i 's:-lhurd-slab:../libhurd-slab/libhurd-slab.a:' Makefile # fix up build system... XXX I guess this part is obsolete
+	$ sed -i 's:-lhurd-slab:../libhurd-slab/libhurd-slab.a:' Makefile # fix up build system... XXX I guess this part is obsolete
 
-> $ sed -i 's:-I/include:-I..:' Makefile # same
+	$ sed -i 's:-I/include:-I..:' Makefile # same
 
-> $ nano forcedeth.c # Near the top of the file, there will be many #include lines. After the last one, add this:
+	$ nano forcedeth.c # Near the top of the file, there will be many #include lines. After the last one, add this:
 
     #include 
 
-> $ cd ..
+	$ cd ..
 
 Commit the new driver with git.
 This will be helpful if we update the DDE code later;
 as well as for creating a patch for later reuse
 and/or upstream submission:
 
-> $ git add dde_forcedeth
+	$ git add dde_forcedeth
 
-> $ git commit -a -m 'Add forcedeth driver'
+	$ git commit -a -m 'Add forcedeth driver'
 
 
 Having prepared the driver,
 we can now build the necessary Hurd and DDE bits:
 
-> $ autoreconf -i && ./configure
+	$ autoreconf -i && ./configure
 
-> $ mkdir -p hurd/include/ddekit # workaround for a buildsystem bug... XXX I'm pretty sure this is not necessary anymore
+	$ mkdir -p hurd/include/ddekit # workaround for a buildsystem bug... XXX I'm pretty sure this is not necessary anymore
 
-> $ make libddekit libmachdev devnode pfinet # Hurd components
+	$ make libddekit libmachdev devnode pfinet # Hurd components
 
-> $ cd libdde_linux26 # common DDE driver code -- uses a different Makefile system than the Hurd components!
+	$ cd libdde_linux26 # common DDE driver code -- uses a different Makefile system than the Hurd components!
 
-> $ make
+	$ make
 
-> $ cd ../dde_forcedeth # actual driver
+	$ cd ../dde_forcedeth # actual driver
 
-> $ make
+	$ make
 
 Install the various built components to their final destinations (as root):
 
-> $ cd ~me/dde/
+	$ cd ~me/dde/
 
-> $ cp gnumach/gnumach /boot/gnumach_dde
+	$ cp gnumach/gnumach /boot/gnumach_dde
 
-> $ mkdir /hurd/dde
+	$ mkdir /hurd/dde
 
-> $ cp hurd/devnode/devnode hurd/pfinet/pfinet hurd/dde_forcedeth/dde_forcedeth /hurd/dde
+	$ cp hurd/devnode/devnode hurd/pfinet/pfinet hurd/dde_forcedeth/dde_forcedeth /hurd/dde
 
 
 Now everything should be ready.
@@ -197,14 +197,14 @@ in the boottime grub menu while testing.)
 
 Once there, set up the translators for the driver (as root):
 
-> $ settrans -c /dev/forcedeth /hurd/dde/forcedeth
+	$ settrans -c /dev/forcedeth /hurd/dde/forcedeth
 
-> $ settrans -c /dev/eth0 /hurd/dde/devnode -M /dev/forcedeth eth0
+	$ settrans -c /dev/eth0 /hurd/dde/devnode -M /dev/forcedeth eth0
 
 Finally, we can set up the actual network translator,
 using something like:
 
-> $ settrans -c /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 -a 192.168.1.194 -g 192.168.1.254 -m 255.255.255.0 
+	$ settrans -c /servers/socket/2 /hurd/dde/pfinet -i /dev/eth0 -a 192.168.1.194 -g 192.168.1.254 -m 255.255.255.0 
 
 For the exact syntax,
 see the normal network setup documentation.
-- 
cgit v1.2.3


From ee740619cc27f30c5c0a7710e740b42144804702 Mon Sep 17 00:00:00 2001
From: antrik 
Date: Sun, 10 Jul 2011 03:17:02 +0200
Subject: dde/guide [discussion]: Add ToDo

---
 hurd/dde/guide/discussion.mdwn | 15 +++++++++++++++
 1 file changed, 15 insertions(+)
 create mode 100644 hurd/dde/guide/discussion.mdwn

(limited to 'hurd')

diff --git a/hurd/dde/guide/discussion.mdwn b/hurd/dde/guide/discussion.mdwn
new file mode 100644
index 00000000..b24b69e7
--- /dev/null
+++ b/hurd/dde/guide/discussion.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]]."]]"""]]
+
+ToDo:
+
+* This guide is probably out of date in some points: the build system got reworked in the meantime I believe...
+* The formatting here needs serious cleanup
+* Might be nice to explain how to find out the right Linux driver, and in which source file it resides
-- 
cgit v1.2.3


From e12e319bf5e4e88c73d9531fef5ab6f80683ab05 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sun, 10 Jul 2011 14:05:56 +0200
Subject: hurd/dde/guide/discussion: Tag open_issue_documentation.

---
 hurd/dde/guide/discussion.mdwn | 2 ++
 1 file changed, 2 insertions(+)

(limited to 'hurd')

diff --git a/hurd/dde/guide/discussion.mdwn b/hurd/dde/guide/discussion.mdwn
index b24b69e7..a1cccad4 100644
--- a/hurd/dde/guide/discussion.mdwn
+++ b/hurd/dde/guide/discussion.mdwn
@@ -10,6 +10,8 @@ License|/fdl]]."]]"""]]
 
 ToDo:
 
+[[!tag open_issue_documentation]]
+
 * This guide is probably out of date in some points: the build system got reworked in the meantime I believe...
 * The formatting here needs serious cleanup
 * Might be nice to explain how to find out the right Linux driver, and in which source file it resides
-- 
cgit v1.2.3


From 1c8909017d006c8e4afeea6d1a1efdebe26fc6b0 Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Fri, 15 Jul 2011 22:46:18 +0200
Subject: IRC.

---
 faq/how_many_developers/discussion.mdwn            |  20 +++
 glibc/discussion.mdwn                              |  25 +++
 hurd/running/qemu.mdwn                             |   3 +
 hurd/running/virtualbox.mdwn                       |   6 +
 hurd/settrans/discussion.mdwn                      |  18 ++
 microkernel/mach/gnumach/debugging.mdwn            |  15 +-
 microkernel/mach/gnumach/memory_management.mdwn    |  30 ++++
 microkernel/mach/rpc/discussion.mdwn               | 117 ++++++++++++
 open_issues/debugging.mdwn                         |   2 +
 .../debugging_gnumach_startup_qemu_gdb.mdwn        | 116 ++++++++++++
 open_issues/gnumach_constants.mdwn                 |  32 ++++
 open_issues/gnumach_kernel_threads.mdwn            |  23 +++
 open_issues/gnumach_memory_management.mdwn         |  65 ++++++-
 .../placement_of_virtual_memory_regions.mdwn       |  89 ++++++++++
 open_issues/rework_gnumach_ipc_spaces.mdwn         | 197 ++++++++++++++++++++-
 open_issues/translate_fd_or_port_to_file_name.mdwn |  36 +++-
 open_issues/xattr.mdwn                             |  27 +++
 17 files changed, 801 insertions(+), 20 deletions(-)
 create mode 100644 faq/how_many_developers/discussion.mdwn
 create mode 100644 glibc/discussion.mdwn
 create mode 100644 hurd/settrans/discussion.mdwn
 create mode 100644 microkernel/mach/rpc/discussion.mdwn
 create mode 100644 open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
 create mode 100644 open_issues/gnumach_constants.mdwn
 create mode 100644 open_issues/gnumach_kernel_threads.mdwn
 create mode 100644 open_issues/placement_of_virtual_memory_regions.mdwn
 create mode 100644 open_issues/xattr.mdwn

(limited to 'hurd')

diff --git a/faq/how_many_developers/discussion.mdwn b/faq/how_many_developers/discussion.mdwn
new file mode 100644
index 00000000..9fc44f25
--- /dev/null
+++ b/faq/how_many_developers/discussion.mdwn
@@ -0,0 +1,20 @@
+[[!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-09
+
+     gnu_srs1: regarding your question why people aren't interested in
+      workin on Hurd: Eric Raymond explains it pretty well in his famous
+      "Cathedral and Bazaar" paper
+     people are more likely to work on something that *almost* works
+      for them, and where they only have to fill in a few missing bits
+     the Hurd doesn't almost work for anyone
+     actually, you should probably reread the whole paper. it's
+      essentially an analysis why the Hurd failed compared to Linux
diff --git a/glibc/discussion.mdwn b/glibc/discussion.mdwn
new file mode 100644
index 00000000..17b4fb32
--- /dev/null
+++ b/glibc/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]]."]]"""]]
+
+
+# TLS
+
+
+## IRC, freenode, #hurd, 2011-06-11
+
+[[!tag open_issue_documentation]]
+
+     youpi: local-tls-support.diff removes libc-tsd.h; what's the
+      rationale?
+     it's completely replaced by __thread variables
+     ok, but apparently there are still libc headers that #include it
+     like malloc-machine.h
+     they'll include bits/libc-tsd.h instead
+     oh, ok
diff --git a/hurd/running/qemu.mdwn b/hurd/running/qemu.mdwn
index 4766b2be..9f085d24 100644
--- a/hurd/running/qemu.mdwn
+++ b/hurd/running/qemu.mdwn
@@ -60,6 +60,9 @@ Check if your CPU supports kvm:
 
 Do not enable kernel-kqemu, as that assumes some particular behavior from the guest kernel, which we are reluctant to artificially add to gnumach.
 
+If QEMU with KVM is not available, [[Virtualbox]] reportedly has better
+performance.
+
 #### If you have hardware support (recommended):
     $ apt-get install qemu-kvm
     $ modprobe kvm
diff --git a/hurd/running/virtualbox.mdwn b/hurd/running/virtualbox.mdwn
index 02ab88e7..0731b8d6 100644
--- a/hurd/running/virtualbox.mdwn
+++ b/hurd/running/virtualbox.mdwn
@@ -20,3 +20,9 @@ supported.
 
 The network controller should be configured as PCnet-PCI II or PCNet-FAST III
 for instance. INTEL PRO or Paravirtualized Network do not work.
+
+
+# Performance
+
+If [[QEMU with KVM|qemu]] is not available, VirtualBox reportedly has better
+performance.
diff --git a/hurd/settrans/discussion.mdwn b/hurd/settrans/discussion.mdwn
new file mode 100644
index 00000000..c9ec4d34
--- /dev/null
+++ b/hurd/settrans/discussion.mdwn
@@ -0,0 +1,18 @@
+[[!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-06-01
+
+     ugh... I just realized why settrans -a without -f doesn't
+      generally work on filesystem translators
+     obviously, it needs -R too!
diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn
index 3a93c6ad..2f52adf8 100644
--- a/microkernel/mach/gnumach/debugging.mdwn
+++ b/microkernel/mach/gnumach/debugging.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]]."]]"""]]
 
 Mach has a built-in kernel debugger.
 [Manual](http://www.gnu.org/software/hurd/gnumach-doc/Kernel-Debugger.html).
@@ -67,3 +67,12 @@ The call of `halt_cpu` will -- as the name suggests -- halt the system
 afterwards.  This might be what you want or it might not, but it is needed at
 some place when running the kernel inside QEMU, as QEMU somehow decides not to
 update its display buffer anymore under certain conditions.
+
+
+IRC, freenode, #hurd, 2011-07-14:
+
+     one ugly trick i use when printf isn't available is to halt the
+      cpu
+     then use info registers to know where the cpu is halted
+     and you'll know if you reached that code or not
+     (info registers is a qemu command)
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 17c7ad79..43b99d83 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -50,3 +50,33 @@ IRC, freenode, #hurd, 2011-02-16
      antrik: but you're right, since mach uses a direct mapped kernel
       space, the true problem is the lack of linux-like highmem support
      which isn't required if the kernel space is really virtual
+
+
+---
+
+IRC, freenode, #hurd, 2011-06-09
+
+     btw, how can gnumach use 1 GiB of RAM ? did you lower the
+      user/kernel boundary address ?
+     I did
+     2G ?
+     yes
+     ok
+     it doesn't make so much sense to let processes have 3G addressing
+      space when there can't be more that 1G physical memory
+     that's sad for an operating system which does most things by
+      mapping memory eh
+     well, if a process wants to map crazy things, 3G may be tight
+      already
+     e.g. ext2fs
+     yes
+     so there's little point in supporting them
+     we need hurd/amd64
+     and there's quite some benefit in shrinking them to 2G
+     yes
+     actually even 2G may become a bit tight
+     webkit linking needs about 1.5-2GiB
+     things become really crazy
+     wow
+     i remember the linux support for 4G/4G split when there was enough
+      RAM to fill the kernel space with struct page entries
diff --git a/microkernel/mach/rpc/discussion.mdwn b/microkernel/mach/rpc/discussion.mdwn
new file mode 100644
index 00000000..00e4a012
--- /dev/null
+++ b/microkernel/mach/rpc/discussion.mdwn
@@ -0,0 +1,117 @@
+[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]]
+
+[[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
+id="license" text="Permission is granted to copy, distribute and/or modify this
+document under the terms of the GNU Free Documentation License, Version 1.2 or
+any later version published by the Free Software Foundation; with no Invariant
+Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
+
+[[!tag open_issue_documentation]]
+
+
+# IRC, freenode, #hurd, 2011-06-11
+
+     I don't think we have a precendence case of Mach initiating RPCs
+      to userspace tasks
+     well mach regularly sends RPCs to external pagers
+     hm, right
+     anyways, the ds_ in device.defs is for use *inside* Mach, not for
+      the userspace interface
+     what makes you think so ?
+     several things
+     not least the fact that without zhengda's modifications, the
+      device handling never calls out to userspace for all I know
+     hm, it does
+     for async I/O
+     when the kernel has finished its I/O, it calls
+      ds_device_read_reply/ds_device_write_reply
+     I see
+     I never quite understood the _reply stuff
+     although i wonder how mig is supposed to forge those names
+     braunr: it isn't
+     braunr: there is a separate device_reply.defs
+     braunr: and it sets a *userprefix* of ds_
+     rather than a serverprefix
+     i saw, yes
+     ah right
+     so ds still refers to the in-Mach device server, not anything
+      userspace
+     so this is where the patch is supposed to introduce the
+      device_intr_notify RPC
+     or at least that's my understanding...
+     no, it doesn't refer to in-mach servers
+     it really forges the right rpcs to be called by mach
+     the definition of "RPC" is rather unclear here
+     why ?
+     mach has its own mach_msg() call for kernel-to-user messaging
+     yes, but this is used only to send the reply message for the RPC
+      earlier initiated by userspace AIUI
+     it doesn't look like there is any special RPC for async I/O
+     yes, because this is the only use case they had
+     hence the name "reply"
+     intr_notify isn't a reply, but it uses the same mechanism
+     these are declared as simpleroutine
+     sure. but the fact that it isn't a reply message, but rather
+      initiates a new RPC, changes things from MiG point of view I believe
+     right, as there is no reply to the reply :-)
+     :)
+     a simpleroutine is how to turn an rpc into a simple ipc
+     I know
+     so in _reply, we pretend that the reply is actually a new RPC,
+      with server and client roles reversed, and no reply
+     (this is actually rather kludgy... apparently MIG has no real
+      notion of async replies)
+     i don't understand what you mean
+     simpleroutine is the explicit solution for async replies
+     as stated in
+      http://www.cs.cmu.edu/afs/cs/project/mach/public/doc/unpublished/mig.ps
+     it's not a new rpc with roles reversed
+     it's not a reply either
+     it might be an explicit solution for that, but it still seems
+      kludgy :-)
+     i don't see why :/
+     would you have expected something like an option to create both
+      sync and async versions ?
+     because it requires an extra .defs file
+     yes
+     ok
+     well this seems cumbersome to me :)
+     i prefer the simpleroutine approach
+     but i agree this seems odd since mach has a high level ipc api
+     anyways, my point is that the ds_ in device_reply.defs still
+      refers to the Mach side of things
+     npnth: which package fails to build ?
+     though a userspace process that actually handles the replies in an
+      async fashion will of course need some kind of device server too, just
+      like the DDE stuff...
+     though naming it ds_ is confusing IMHO, because of the name clash
+      with the device server in Mach
+     hm again, i fail to see why
+     ds_ just means device_server
+     and as most things in mach, it can be in kernel or not
+     i mean, this is an interface prefix, i don't refer to an actual
+      single instance of a "device server" out there
+     oh, right... DDE implements the Mach device protocol, so it *does*
+      do the ds_ part... but that makes the interrupt notification stuff even
+      more confusing
+     hm
+     because it provides a ds_device_intr_notify() which will never be
+      used, just to completely implement the interface ?
+     yeah, that's what I suspect...
+     sounds likely
+     the device interface actually has two parts: one for "generic"
+      RPCs on the master device port, and one for device-specific RPCs. DDE
+      implements the latter, and uses the former...
+     they live in separate places though I think: the individual device
+      RPCs are implemented in libmachdev, while the intr_ stuff is used in
+      libddekit probably
+     it would be hairy to build otherwise
+     so we *really* need to know what component npnth gets the error
+      with
+     braunr: nah, not really. that's why we always have a separate
+      prefix for the server routines in Hurd RPCs
+     right, i really need to read about mig again
+     it's pretty normal for a translator to both implement and use an
+      interface
diff --git a/open_issues/debugging.mdwn b/open_issues/debugging.mdwn
index e5fbf7a0..b2d49b26 100644
--- a/open_issues/debugging.mdwn
+++ b/open_issues/debugging.mdwn
@@ -49,3 +49,5 @@ We have debugging infrastructure.  For example:
 
   * , or  --
     just two examples; there's a lot of such stuff for Linux.
+
+  * [[debugging_gnumach_startup_QEMU_GDB]]
diff --git a/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
new file mode 100644
index 00000000..e3a6b648
--- /dev/null
+++ b/open_issues/debugging_gnumach_startup_qemu_gdb.mdwn
@@ -0,0 +1,116 @@
+[[!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="Debugging GNU Mach's startup in QEMU with GDB"]]
+
+[[!tag open_issue_gdb open_issue_gnumach]]
+
+
+# IRC, freenode, #hurd, 2011-07-14
+
+     Hello. I have problem with debugging gnumach. I set 2 brakepoints
+      in file i386/i386at/model_dep.c on functions gdt_init and idt_init. Then
+      I start qemu with patched gnumach kernel and stop at gdt_init. When I
+      enter command "continue" in gdb, qemu hangs. But when I go step by step,
+      using command "next", I freely reach idt_init. What can cause this
+      problem?
+     hm
+     not sure
+     let me try
+     mcsim: works for me :/
+     it works without my patch, but with it qemu hangs
+     oh, i thought it worked when not using continue
+     with my patch I can reach idt_init only using next
+     and without all works fine
+     mcsim: are you sure you correctly built it with debugging symbols
+      ?
+     I've written in /etc/dpkg/buildflags.conf SET CFLAGS -g3 -O0
+     hm
+     i have internal kvm errors actually
+     mcsim: do you use kvm ?
+     mcsim: and why break on those functions ?
+     i'm not sure the address space is already fine at this point
+     no. I don't have hardware virtualisation support.
+     hm actually, you won't be able to use gdb
+     i just remembered how gnumach is linked and mapped :/
+     the addresses in the elf image are low addresses, matching the
+      image as it is loaded by the boot loader
+     I was wondering why qemu hangs.
+     then the kernel uses segmentation to map itself at 2 (or 3
+      previously) GiB
+     well, if the addresses are wrong, your breakpoints are wrong
+     i even wonder how it can work when stepping
+     i don't have the issue with x15 because of its linker script
+     Are there any ways of such debugging without qemu?
+     i don't think so
+     as antrik told you, the in kernel debugger needs many services
+      running before being usable
+     you'll have to use printf, and there may be steps during bootstrap
+      when even that isn't available
+     So I need computer with hardware virtualisation?
+     well, of course stepping works, since the breakpoints are relative
+     no
+     kvm has nothing to do with the problem
+     it's just that the problem appears differently with kvm enabled
+     ok. thank you.
+     good luck
+     braunr: would it be hard to "fix" gnumach to avoid the
+      segmentation magic?...
+     antrik: because of the linux drivers, it may
+     or alternatively, implement something in GDB to deal with that?...
+     antrik: i didn't study that part enough to know for sure
+     uhm... why would the Linux drivers depend on that? does Linux also
+      do such magic?...
+     well it should simply be a matter of shifting the address by a
+      fixed offset
+     antrik: linux drivers rely on physical memory being allocated
+      through kmalloc
+     so there must be a direct mapping between virtual kernel memory
+      and physical memory
+     they don't specifically need that segmentation settings
+     so if you remove the offset implemented through segmentation, you
+      have to replace it with page mapping
+     and i don't know how much needs to be done for that
+     you also need to link the kernel differently
+     hm, OK
+     so adding GDB support for the offset would probably be easier...
+     yes
+     but using the offset must only be done once segmentation is set up
+     so you must break after gdt_init
+     not on it
+     mcsim: why do you break on these functions btw ?
+     I just wanted to find out why qemu hangs
+     yes but why those ?
+     I found out that before gdt_init all workes fine, but after qemu
+      hangs. So idt_init is just the next function
+     ok
+     and does your patch change something to how segmentation is
+      initialized ?
+     now
+     no
+     try to build it with the regular cflags
+     i don't know if gnumach can work with -O0
+     I've tried. But all the same
+     Regular are -g -O2
+     can you make your patch available ?
+     yes
+     it is available in gnumach repository at savannah 
+     tree mplaneta/libbraunr/master
+     well, if the segmentation stuff is the thing GDB has problems
+      with, I don't see how it can work without your patch...
+     without ?
+     well, the patch shouldn't affect the segmentation... so I don't
+      see how it can make a difference
+     he said qemu hanged
+     so let's not introduce gdb yet
+     qemu can hang for other reasons
+     oh, right, without GDB...
+     though if that's what he meant, his statement was very misleading
+      at least
diff --git a/open_issues/gnumach_constants.mdwn b/open_issues/gnumach_constants.mdwn
new file mode 100644
index 00000000..16c8cf41
--- /dev/null
+++ b/open_issues/gnumach_constants.mdwn
@@ -0,0 +1,32 @@
+[[!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]]
+
+At compile-time, GNU Mach is parameterized with several constants.  These might
+need some tuning.  Debian has some patches.
+
+
+# IRC, freenode, #hurd, 2011-06-09
+
+     youpi: in ipc/ipc_hash.c, there is code which computes the size of
+      the global (space, port)->entry hash table
+     youpi: you may be interested in tuning this one too
+     I know
+     ok
+     the current value is not so bad
+     it's big enough for buildds to run fine
+     256 if i'm right
+     well
+     it won't fail
+     we're limited by the 4000 object limitation anyway
+     since it's a chained hash table
+     but increasing it may help performances a bit
+     and it certainly can't hurt much
diff --git a/open_issues/gnumach_kernel_threads.mdwn b/open_issues/gnumach_kernel_threads.mdwn
new file mode 100644
index 00000000..9591986b
--- /dev/null
+++ b/open_issues/gnumach_kernel_threads.mdwn
@@ -0,0 +1,23 @@
+[[!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-07-13
+
+     jkoenig: why does gnumach appear as "root=device:hd0s1" in ps ?
+     braunr, it's the closest we can do to its command line
+     doesn't it deserve something special like kernel threads in linux
+      ?
+     so that it's actually clear that it's a special task/process
+     you mean something like [mach root=device:hd0s1] ?
+     something like that yes
+     also, it would be nice if gnumach threads could actually be seen,
+      i don't remember if the mach interface allows it though
diff --git a/open_issues/gnumach_memory_management.mdwn b/open_issues/gnumach_memory_management.mdwn
index a5dd6955..f15c4d25 100644
--- a/open_issues/gnumach_memory_management.mdwn
+++ b/open_issues/gnumach_memory_management.mdwn
@@ -12,7 +12,10 @@ License|/fdl]]."]]"""]]
 
 There is a [[!FF_project 266]][[!tag bounty]] on this task.
 
-IRC, freenode, #hurd, 2011-04-12:
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2011-04-12
 
      braunr: do you think the allocator you wrote for x15 could be used
       for gnumach? and would you be willing to mentor this? :-)
@@ -597,7 +600,8 @@ IRC, freenode, #hurd, 2011-04-12:
      It would be better to rewrite it using debugfs, but when I was
       writing this test I didn't know about trace_* macros
 
-2011-04-15
+
+# IRC, freenode, #hurd, 2011-04-15
 
      There is a hack in zone_gc when it allocates and frees two
       vm_map_kentry_zone elements to make sure the gc will be able to allocate
@@ -632,7 +636,8 @@ IRC, freenode, #hurd, 2011-04-12:
      i think that's why i have "sources" in my slab allocator, the
       default source (vm_kern) and a custom one for kernel map entries
 
-2011-04-18
+
+# IRC, freenode, #hurd, 2011-04-18
 
      braunr: you've said that once page is completely free, it is
       returned to the vm.
@@ -640,7 +645,8 @@ IRC, freenode, #hurd, 2011-04-12:
      mcsim: i also said i was wrong about that
      zone_gc is the only one
 
-2011-04-19
+
+# IRC, freenode, #hurd, 2011-04-19
 
      antrik: mcsim: i added back a new per-cpu layer as planned
     
@@ -649,7 +655,8 @@ IRC, freenode, #hurd, 2011-04-12:
       loops, just as in zone_gc, to reduce contention and avoid deadlocks
      this is really common in memory allocators
 
-2011-04-23
+
+# IRC, freenode, #hurd, 2011-04-23
 
      I've looked through some allocators and all of them use different
       per cpu cache policy. AFAIK gnuhurd doesn't support multiprocessing, but
@@ -661,7 +668,8 @@ IRC, freenode, #hurd, 2011-04-12:
      I'm not sure I suggested that explicitly to you; but probably it
       makes most sense to use that in gnumach
 
-2011-04-24
+
+# IRC, freenode, #hurd, 2011-04-24
 
      antrik: Yes, I have. He uses both global and per cpu caches. But he
       also suggested to look through slqb, where there are only per cpu
@@ -773,7 +781,8 @@ IRC, freenode, #hurd, 2011-04-12:
      the fact that the kernel allocator uses virtual memory doesn't
       mean the kernel has no mean to allocate contiguous physical memory ...
 
-2011-05-02
+
+# IRC, freenode, #hurd, 2011-05-02
 
      hm nice, my allocator uses less memory than glibc (squeeze
       version) on both 32 and 64 bits systems
@@ -822,7 +831,8 @@ IRC, freenode, #hurd, 2011-04-12:
      it could also be used to drop the overloaded (and probably over
       imbalanced) page cache hash table
 
-2011-05-03
+
+# IRC, freenode, #hurd, 2011-05-03
 
      antrik: How should I start porting? Have I just include rbraun's
       allocator to gnumach and make it compile?
@@ -845,3 +855,42 @@ IRC, freenode, #hurd, 2011-04-12:
      there is work to be done ;)
      (not to mention the obvious about replacing all the calls to the
       zone allocator, and testing/debugging afterwards)
+
+
+# IRC, freenode, #hurd, 2011-07-14
+
+     can you make your patch available ?
+     it is available in gnumach repository at savannah 
+     tree mplaneta/libbraunr/master
+     mcsim: i'll test your branch
+     ok. I'll give you a link in a minute
+     hm why balloc ?
+     Braun's allocator
+     err
+    
+      http://git.sceen.net/rbraun/x15mach.git/?a=blob;f=kern/kmem.c;h=37173fa0b48fc9d7e177bf93de531819210159ab;hb=HEAD
+     mcsim: this is the interface i had in mind for a kernel version :)
+     very similar to the original slab allocator interface actually
+     well, you've been working
+     But I have a problem with this patch. When I apply it to gnumach
+      code from debian repository. I have to make a change in file ramdisk.c
+      with sed -i 's/kernel_map/\&kernel_map/' device/ramdisk.c
+     because in git repository there is no such file
+     mcsim: how do you configure the kernel before building ?
+     mcsim: you should keep in touch more often i think, so that you
+      get feedback from us and don't spend too much time "off course"
+     I didn't configure it. I just run dpkg-buildsource -b.
+     oh you build the debian package
+     well my version was by configure --enable-kdb --enable-rtl8139
+     and it seems stuck in an infinite loop during bootstrap
+     and printf doesn't work. The first function called by c_boot_entry
+      is printf(version).
+     mcsim: also, you're invited to get the x15mach version of my
+      files, which are gplv2+ licensed
+     be careful of my macros.h file, it can conflict with the
+      macros_help.h file from gnumach iirc
+     There were conflicts with MACRO_BEGIN and MACRO_END. But I solved
+      it
+     ok
+     it's tricky
+     mcsim: try to find where the first use of the allocator is made
diff --git a/open_issues/placement_of_virtual_memory_regions.mdwn b/open_issues/placement_of_virtual_memory_regions.mdwn
new file mode 100644
index 00000000..95b9e545
--- /dev/null
+++ b/open_issues/placement_of_virtual_memory_regions.mdwn
@@ -0,0 +1,89 @@
+[[!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-07-13
+
+     does anyone know if posix (or mach) has requirements or a policy
+      about the placement of allocations of virtual space ?
+     a policy such as bottom-up ?
+     or "find lowest vailable space" ?
+     braunr, you mean for vm_allocate ? You may want to check mmap()
+      but I can't remember ever coming across such a thing (except maybe
+      wrt. alignment)
+     i was wondering how e.g. libraries are linked near the stack
+      (possibly at slightly random addresses)
+     does the linker walk the address space entries top-down ?
+     jkoenig: i didn't see anything either in the mach interface, but i
+      may have missed something
+     jkoenig: most systems i've been studying mark the vm regions for
+      the heap and the stack
+     but for mach, the stack is just allocated virtual memory at the
+      top of the space
+     so the "placement policy" is either completely outside the kernel,
+      or relies on its interface
+     braunr, actually I'm surprised Mach would even dictate where the
+      (one?) stack should be, I would have expected  it to be the job of
+      whatever creates a thread to make this kind of choice
+     jkoenig: threads have their own stacks, under the responsibility
+      of the user trhead implementation
+     but a program usually needs a stack even before it runs
+     i had to set one to bootstrap modules in v0.1
+     but i wonder if it's just for bootstrapping (and then propagated
+      by fork()) or part of the interface
+     but this doesn't matter much actually, the allocation mechanism i
+      have in mind can actually support multiple policies
+     I would guess the former (just for bootstrapping), since a new
+      task has no thread, and a new thread has no state. (but I'm no expert)
+     i think so
+     i'll have a look at the exec server
+     jkoenig: did the previous implementation of procfs show task maps
+      ?
+     braunr, I don't think so, I would probably have felt compelled to
+      include them in the new one if it did :-)
+     hmmm
+     we definitely need that
+     is there a compelling use case you think about in particular?
+     yes
+     i failed to understand how gnumach behaved wrt ipc right spaces
+
+[[rework_gnumach_ipc_spaces]]
+
+     and when i did, i found out my work was impossible to integrate
+     "ipc right spaces" ?
+     each task have an ipc space, which contains righs
+     rights
+     the ipc translation layer converts space/name and space/port
+      tuples to rights
+     i wanted to replace the splay tree with a radix tree but didn't
+      get how the ipc table made the splay tree almost unused
+     i don't want to make this kind of mistake again, so i'd like a
+      clear and detailed view of the vm spaces
+     (it's only compelling for myself, all right)
+     but
+     we have vminfo
+     rbraun@nordrassil:~$ vminfo $$ | wc -l
+     1046
+     oh my
+     in comparison, a firefox instance has less than 500 on linux
+     you mean there's some kind of port name table (or functional
+      equivalent) which actually resides in the task's memory? (and that's what
+      shows up at the beginning of the address space with prot=0?)
+     jkoenig: sorry for being confusing, it's not that at all
+     (btw feel free to tell me to just go read the source or whatever)
+     jkoenig: don't worry
+     braunr, no problem
+     jkoenig: i just compared a previous attempt to improve gnumach
+      which failed because i didn't have enough insight of the inner workings
+      of the kernel
+     jkoenig: i really want to miss as little as possible on the vm
+      part, so having detailed information about what actually happens on
+      running hurd systems is something i need
diff --git a/open_issues/rework_gnumach_ipc_spaces.mdwn b/open_issues/rework_gnumach_ipc_spaces.mdwn
index f5d40abd..b3d1b4a4 100644
--- a/open_issues/rework_gnumach_ipc_spaces.mdwn
+++ b/open_issues/rework_gnumach_ipc_spaces.mdwn
@@ -10,7 +10,10 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_gnumach]]
 
-IRC, freenode, #hurd, 2011-05-07
+[[!toc]
+
+
+# IRC, freenode, #hurd, 2011-05-07
 
      things that are referred to as "system calls" in glibc are
       actually RPCs to the kernel or other tasks, those RPCs have too lookup
@@ -20,7 +23,8 @@ IRC, freenode, #hurd, 2011-05-07
 
 There is a [[!FF_project 268]][[!tag bounty]] on this task.
 
-IRC, freenode, #hurd, 2011-04-23
+
+# IRC, freenode, #hurd, 2011-04-23
 
      youpi: is there any use of the port renaming facility ?
      I don't know
@@ -250,7 +254,8 @@ IRC, freenode, #hurd, 2011-04-23
      well, if some processes really feel they must use random numbers
       for port names, they *ought* to be penalized ;-)
 
-2011-04-27
+
+# IRC, freenode, #hurd, 2011-04-27
 
      antrik: remember when you asked why high numbers would be a
       problem with radix trees ?
@@ -319,7 +324,182 @@ IRC, freenode, #hurd, 2011-04-23
      antrik: a data structure used to map integers to pointers
      http://fxr.watson.org/fxr/source/lib/idr.c?v=linux-2.6
 
-2011-06-18
+
+# IRC, freenode, #hurd, 2011-06-08
+
+     hm, reverse space/port to name lookups also suck
+     having separate types for simple ipc entries and splay tree
+      entries really makes many parts of the ipc code complicated
+     and a global hash table for these operations is scary
+
+
+# IRC, freenode, #hurd, 2011-06-09
+
+     hm nice, my radix tree code runs inside gnumach, along with the
+      original splay tree code and assertions making sure results are the same
+     there is this "collision" thing i'm not sure to understand but
+      once this is solved, replacing the splay trees should be easy
+
+     youpi: is there a way to easily know the number of send rights
+      associated to a port ?
+     portinfo ?
+     portinfo gives information in a space
+     but this is specific to a port
+     is there an option for that ?
+     -v
+     hm ok
+         25: send (refs: 550)
+     nice
+     youpi: if you have time, could you give me the min/max/avg numbers
+      of send rights referring to the same port on buildds ?
+     i'm trying to estimate if it's better to have space->list_of_ports
+      or port->list_of_spaces to replace the global ipc hash table
+     the latter seems better but there could be unexpected cases on
+      machines using large amounts of resources like the buildds
+     max is 64k
+     min is 1 of course :)
+     64k
+     then it's not what i'm looking for
+     avg is 55
+     isn't this the number of urefs ?
+     I don't know
+     hmm
+     what i'm looking for is the number of *pure send rights* for the
+      same port
+     i don't think portinfo can give it
+     there can only be one such send right per task for the same port
+     64k would mean there are 64k tasks
+     ok, so it's more difficult
+     it means using -t
+     ahh
+     and run n^2 portinfo over the n processes
+     i see
+     Mmm, that will however still show any duplicate send right
+     but then by min/max/avg, you mean, over time ?
+     i'll change the source code, simpler
+     e.g. min would be right after boot?
+     min is 1
+     1 what ?
+     1 send right to a port
+     ah, 1 for a given port
+     yes
+     ok, it becomes really hairy to compute, I don't hav ethe time :)
+     avg and max are more interesting :)
+     no worries
+     braunr: I wouldn't be surprised that max is the number of tasks
+     e.g. for a send port to the proc server for instance
+     youpi: it is, but i'm not looking for potential numbers
+     I'm not talking about a potential number, but an actual number
+      that's almost always true
+     for one port, yes
+     but yes, ok for max
+     this makes choosing an appropriate data structure difficult
+
+     braunr: actually, min number of send rights to a port is 0... but
+      I'm sure you know that already :-)
+
+     youpi: normally each client gets a separate port. I'm not sure
+      there are any ports with send rights distributed over many tasks...
+
+     antrik, what about / ?
+
+     antrik: not necessarily
+
+     jkoenig: not sure... isn't the "/" port authenticated to the
+      specific user?
+
+     antrik, I guess so, but a single user could still have many
+      tasks.
+     (wrt /)
+     jkoenig: well, in theory the tasks having exactly the same UIDs
+      and GITs could probably share an auth token... but that's not how things
+      are handled in general
+     at least I don't think so
+     tasks are authenticated, not users
+     err... GIDs :-)
+     antrik, still, my quick glance to the fork() code seemed to
+      indicate the port is inherited as-is, maybe authentication happens only
+      when something is actually looked up?
+     hmm "rpctrace ls -d /" does not show any authentication calls,
+      only a lookup("") on the root which returns a different port
+     so I guess the root port is "deauthenticated" or something when
+      the uid of a process is changed.
+     too bad cfhammer isn't around, he digged into all this stuff...
+     I know that there is a mechanism which reauths all FDs when the
+      IDs of a process change
+     but I'm not sure the "/" port uses this mechanism
+
+     antrik: but the radix tree codee is really used as is, which means
+      no locking, no preloading before locking, all of this because simple
+      locks don't exist on UP, and because the kernel isn't preemptible
+
+     antrik: and yes, min number is 0, but in that case you don't need
+      (space, port) -> right lookups :)
+     antrik: or put in another way, whichever reasonable structure you
+      use, when it's empty, you don't care much
+     which also means that the min number has actually no value here
+     because the same applies to 1
+
+     then what seems to take most time is forks
+     and i hope my upcoming kernel changes will help the situation a
+      bit
+     what are your incoming gnumach changes about?
+     the ipc translation layer speed
+     which basically means operating on port names (looking them up,
+      inserting, removing, renaming, looking up send rights to a specific
+      ports) will be faster
+     and i believe forks are (one of) the most demanding use cases wrt
+      ipc space manipulation
+     i'm really surprised how badly the splay trees are used
+     the worst case for this data structure is traversal
+     and this is done in many situations
+     leaving the tree in its worst case shape
+     and i didn't mentioned the bunch of memory writes occurring, event
+      for things like lookups or traversals
+     this is slow and can disrupt many cpu cache lines
+     and when there are 10k to 100+k (e.g. in some ext2fs instances on
+      buildds), just imagine the number of operations involved in those
+      operations
+     a simple traversal_next involves a rotation *gasp*
+     this means potentially writing on 3 different cache lines, for
+      *one* next operation
+     what are you replacing that splay tree with?
+     radix trees
+     much shorter paths
+     extremely few memory writes
+     locality of reference when traversing
+     good cache usage (as many of the top nodes are reused)
+     the two drawbacks are 1/ memory allocation for external nodes,
+      which means the tree must be preloaded before locking
+     and 2/ high memory overhead if the keys are sparse
+     but this isn't the case with port names, unless someone messes it
+      up by assigning random names to many rights
+
+     braunr: so, when will we see the first performance comparision?
+      :-)
+     antrik: that's a topic of itself, how to compare ?
+     antrik: the thing is, my current gnumach patches only makes
+      assertions
+     this is the best way i found to test my tree in real life
+      conditions
+     much cleanup is needed
+     and what i'd like to do is to completely replace all teh
+      translation layer structures with it
+     which means removing much code, making sure it still works as
+      expected
+     this is tedious
+     so one month at least
+     braunr: comparing shouldn't be too hard... the average configure
+      script does a lot of forking, which should be a good benchmark according
+      to your observations
+     rough estimates are easy, yes
+     but my observations my be wrong :p
+     braunr: well, we don't really need precise numbers...
+     unless you need to do some kind of fine-tuning?
+     i don't know yet
+
+
+# IRC, freenode, #hurd, 2011-06-18
 
     < braunr> hmm, i'm having a problem with integrating my radix tree code in
       gnumach
@@ -373,7 +553,8 @@ IRC, freenode, #hurd, 2011-04-23
     < braunr> not much
     < braunr> testing is what requires time really
 
-2011-06-27
+
+# IRC, freenode, #hurd, 2011-06-27
 
     < braunr> ok, here is the radix tree code:
       http://git.sceen.net/rbraun/libbraunr.git/
@@ -399,7 +580,8 @@ IRC, freenode, #hurd, 2011-04-23
     < youpi> k
     < braunr> before locking the ipc spaces
 
-2011-06-28
+
+# IRC, freenode, #hurd, 2011-06-28
 
     < braunr> antrik: i think i won't write the code for the preloading stuff
       actually
@@ -456,7 +638,8 @@ IRC, freenode, #hurd, 2011-04-23
       only
     < braunr> but released in both the entry and the splay tree code ...
 
-2011-06-29
+
+# IRC, freenode, #hurd, 2011-06-29
 
     < braunr> hmm i missed an important thing :/
     < braunr> and it's scary
diff --git a/open_issues/translate_fd_or_port_to_file_name.mdwn b/open_issues/translate_fd_or_port_to_file_name.mdwn
index 25a74456..485fb985 100644
--- a/open_issues/translate_fd_or_port_to_file_name.mdwn
+++ b/open_issues/translate_fd_or_port_to_file_name.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
@@ -10,7 +10,10 @@ License|/fdl]]."]]"""]]
 
 [[!tag open_issue_glibc open_issue_hurd]]
 
-\#hurd, freenode, June (?) 2010
+[[!toc]]
+
+
+# IRC, freenode, #hurd, June (?) 2010
 
      is there a way (POSIX or Hurdish) to get the corresponding file name for a fd or a hurd port?
      there is a way
@@ -52,3 +55,32 @@ License|/fdl]]."]]"""]]
      which combines file and directory operations
      of course, files and directories implement those functions differently
      marcusb: do you know why this behavior (cat on directories) was changed?
+
+
+# IRC, freenode, #hurd, 2011-07-13
+
+A related issue:
+
+     rbraun@nordrassil:~$ vminfo $$ | wc -l
+     1039
+     any idea why a shell would consume more than 1039 map entries ?
+     (well, not more actually)
+     even the kernel and ext2fs have around 100
+     (the kernel has actually only 23, which is very good and expected)
+     braunr: I agree that having some sort of debugging information
+      for memory objects et al. would be quite hand.  To see where they're
+      coming from, etc.
+     tschwinge: this would require naming objects at the mach level
+     e.g. when creating an object
+     giving it the path of a file for example
+     braunr: I have recently seen something (due to youpi fixing a
+      bug) that bash is doing its own memory management.  Perhaps all these are
+      such regions?
+     braunr: For example, yes.
+     what ?
+     ?!
+     braunr:
+      http://lists.gnu.org/archive/html/bug-bash/2011-04/msg00097.html
+     i see
+
+Also see email thread starting at `id:"20110714082216.GA8335@sceen.net"`.
diff --git a/open_issues/xattr.mdwn b/open_issues/xattr.mdwn
new file mode 100644
index 00000000..8b08ef1e
--- /dev/null
+++ b/open_issues/xattr.mdwn
@@ -0,0 +1,27 @@
+[[!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="xattr: extended attributes"]]
+
+[[!tag open_issue_glibc open_issue_hurd]]
+
+IRC, freenode, #hurd, 2011-06-01
+
+     Another thing: the lsattr and chattr programs seems to be bogus
+      on Hurd. Are they present since they are part of e2fsprogs?
+     I don't think the Hurd has an interface for it
+     gnu_srs, youpi: lsattr/chattr are extended attributes, right?
+      We do have some patches from years ago for adding some support in glibc,
+      but they're not yet integrated.  And also we do have a plan for using
+      these instead of our Hurd-specific passive translator information in
+      inodes.
+
+If interested in working on this, see [[!GNU_Savannah_task
+#5503]]/[[!GNU_Savannah_patch #5126]], and talk to [[tschwinge]].
-- 
cgit v1.2.3


From 66e620b491dd3aebbdcfe6203810e8c579441978 Mon Sep 17 00:00:00 2001
From: Arne Babenhauserheide 
Date: Sat, 16 Jul 2011 01:07:59 +0200
Subject: Added a small translator primer; copied from the text I wrote for the
 babhurd qemu image -> hereby the sourcecode is assigned :)

---
 hurd/documentation/translator-primer.mdwn | 57 +++++++++++++++++++++++++++++++
 1 file changed, 57 insertions(+)
 create mode 100644 hurd/documentation/translator-primer.mdwn

(limited to 'hurd')

diff --git a/hurd/documentation/translator-primer.mdwn b/hurd/documentation/translator-primer.mdwn
new file mode 100644
index 00000000..67c52977
--- /dev/null
+++ b/hurd/documentation/translator-primer.mdwn
@@ -0,0 +1,57 @@
+Small examples on using translators
+===================================
+
+## Intro
+
+The Hurd has some unique capabilities, and we created this simple image 
+to enable you to easily try two of them: 
+
+* The simplest of translators: Hello World!
+* Transparent FTP
+
+### Hello World
+
+To try out the simplest of translators, you can go the following simple steps: 
+
+	$ cat hello  
+	$ setrans hello /hurd/hello  
+	$ cat hello  
+	"Hello World!"  
+	$ settrans -g hello  
+	$ cat hello  
+
+What you do with these steps is first verifying that the file "hello" is empty. 
+
+Then you setup the translator /hurd/hello in the file/node hello. 
+
+After that you check the contents of the file, and the translator returns "Hello World!". 
+
+To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. 
+
+### Transparent FTP
+
+We already setup a a transparent FTP translator for you at /ftp: 
+
+With it you can easily access public FTP via the file system, for example the one from the GNU project: 
+
+	$ ls /ftp://ftp.gnu.org/
+
+But you can also do this very easily yourself: 
+
+	$ # Setup the translator on the node ftp:  
+	$ settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
+
+and you can access FTP sites via the pseudo-directory ftp:, for example with 
+
+	$ ls ftp://ftp.gnu.org/
+
+What you do here is setting up the translator /hurd/hostmux on ftp: and passing it the translator /hurd/ftpfs to use for resolving accesses as well as / as additional path component. 
+
+
+These were only two basic usages of translators on the Hurd. We're sure you'll quickly see many other ways to use this. 
+
+As a last comment: You can setup a translator on any node you have access to, so you can for example mount any filesystems as normal user. 
+
+You might currently be logged in as root, but you could just as well do the same as normal user. 
+
+Why don't you try it out? 
-- 
cgit v1.2.3


From 49deddce82fbb5ab4020815d4a59390b655ff16c Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 16 Jul 2011 11:55:43 +0200
Subject: Properly integrate the translator primer.

---
 hurd/documentation.mdwn                   |  4 +-
 hurd/documentation/translator-primer.mdwn | 57 -------------------------
 hurd/documentation/translator_primer.mdwn | 70 +++++++++++++++++++++++++++++++
 hurd/translator.mdwn                      |  2 +
 4 files changed, 75 insertions(+), 58 deletions(-)
 delete mode 100644 hurd/documentation/translator-primer.mdwn
 create mode 100644 hurd/documentation/translator_primer.mdwn

(limited to 'hurd')

diff --git a/hurd/documentation.mdwn b/hurd/documentation.mdwn
index 874ce847..48fd017c 100644
--- a/hurd/documentation.mdwn
+++ b/hurd/documentation.mdwn
@@ -1,5 +1,5 @@
 [[!meta copyright="Copyright © 2001, 2002, 2003, 2004, 2005, 2006, 2007, 2008,
-2009 Free Software Foundation, Inc."]]
+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
@@ -24,6 +24,8 @@ is included in the section entitled
 
   * [[*The_Hurd*|/hurd-talk]], a presentation by Marcus Brinkmann.
 
+  * The *[[translator_primer]]*.
+
   * A document about *[[translators]]* by Marcus Brinkmann.
 
   * [[*A_Critique_of_the_GNU_Hurd_Multi-server_Operating_System*|critique]], an
diff --git a/hurd/documentation/translator-primer.mdwn b/hurd/documentation/translator-primer.mdwn
deleted file mode 100644
index 67c52977..00000000
--- a/hurd/documentation/translator-primer.mdwn
+++ /dev/null
@@ -1,57 +0,0 @@
-Small examples on using translators
-===================================
-
-## Intro
-
-The Hurd has some unique capabilities, and we created this simple image 
-to enable you to easily try two of them: 
-
-* The simplest of translators: Hello World!
-* Transparent FTP
-
-### Hello World
-
-To try out the simplest of translators, you can go the following simple steps: 
-
-	$ cat hello  
-	$ setrans hello /hurd/hello  
-	$ cat hello  
-	"Hello World!"  
-	$ settrans -g hello  
-	$ cat hello  
-
-What you do with these steps is first verifying that the file "hello" is empty. 
-
-Then you setup the translator /hurd/hello in the file/node hello. 
-
-After that you check the contents of the file, and the translator returns "Hello World!". 
-
-To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. 
-
-### Transparent FTP
-
-We already setup a a transparent FTP translator for you at /ftp: 
-
-With it you can easily access public FTP via the file system, for example the one from the GNU project: 
-
-	$ ls /ftp://ftp.gnu.org/
-
-But you can also do this very easily yourself: 
-
-	$ # Setup the translator on the node ftp:  
-	$ settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
-
-and you can access FTP sites via the pseudo-directory ftp:, for example with 
-
-	$ ls ftp://ftp.gnu.org/
-
-What you do here is setting up the translator /hurd/hostmux on ftp: and passing it the translator /hurd/ftpfs to use for resolving accesses as well as / as additional path component. 
-
-
-These were only two basic usages of translators on the Hurd. We're sure you'll quickly see many other ways to use this. 
-
-As a last comment: You can setup a translator on any node you have access to, so you can for example mount any filesystems as normal user. 
-
-You might currently be logged in as root, but you could just as well do the same as normal user. 
-
-Why don't you try it out? 
diff --git a/hurd/documentation/translator_primer.mdwn b/hurd/documentation/translator_primer.mdwn
new file mode 100644
index 00000000..d8d89148
--- /dev/null
+++ b/hurd/documentation/translator_primer.mdwn
@@ -0,0 +1,70 @@
+[[!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]]."]]"""]]
+
+# Small Examples on Using Translators
+
+The [[concept|concepts]] of user-space servers, [[translator]]s, is a very
+powerful one.  Here is an introductionary text.
+
+
+## Intro
+
+The Hurd has some unique capabilities, and we created this simple image 
+to enable you to easily try two of them: 
+
+* The simplest of translators: Hello World!
+* Transparent FTP
+
+### Hello World
+
+To try out the simplest of translators, you can go the following simple steps: 
+
+	$ cat hello  
+	$ setrans hello /hurd/hello  
+	$ cat hello  
+	"Hello World!"  
+	$ settrans -g hello  
+	$ cat hello  
+
+What you do with these steps is first verifying that the file "hello" is empty. 
+
+Then you setup the translator /hurd/hello in the file/node hello. 
+
+After that you check the contents of the file, and the translator returns "Hello World!". 
+
+To finish it, you tell the translator to go away from the file "hello" via "settrans -g hello" and verify that now the file is empty again. 
+
+### Transparent FTP
+
+We already setup a a transparent FTP translator for you at /ftp: 
+
+With it you can easily access public FTP via the file system, for example the one from the GNU project: 
+
+	$ ls /ftp://ftp.gnu.org/
+
+But you can also do this very easily yourself: 
+
+	$ # Setup the translator on the node ftp:  
+	$ settrans -c ftp: /hurd/hostmux /hurd/ftpfs /
+
+and you can access FTP sites via the pseudo-directory ftp:, for example with 
+
+	$ ls ftp://ftp.gnu.org/
+
+What you do here is setting up the translator /hurd/hostmux on ftp: and passing it the translator /hurd/ftpfs to use for resolving accesses as well as / as additional path component. 
+
+
+These were only two basic usages of translators on the Hurd. We're sure you'll quickly see many other ways to use this. 
+
+As a last comment: You can setup a translator on any node you have access to, so you can for example mount any filesystems as normal user. 
+
+You might currently be logged in as root, but you could just as well do the same as normal user. 
+
+Why don't you try it out? 
diff --git a/hurd/translator.mdwn b/hurd/translator.mdwn
index 6f385b50..aa8b966a 100644
--- a/hurd/translator.mdwn
+++ b/hurd/translator.mdwn
@@ -63,6 +63,8 @@ Also there is an [[writing/example]] about how to write a simple translator.
 
 See some [[examples]] about how to use translators.
 
+There is a [[documentation/translator_primer]].
+
 Marcus Brinkmann has written a document about [[documentation/translators]].
 
 Here are some [[hints_about_debugging_translators|debugging/translator]]
-- 
cgit v1.2.3


From 513f7e4fb43325b346b23949c01d66f8f243764d Mon Sep 17 00:00:00 2001
From: Thomas Schwinge 
Date: Sat, 16 Jul 2011 12:44:20 +0200
Subject: open_issues/librpci: New.

---
 hurd/debugging/rpctrace.mdwn | 13 +++++++++----
 microkernel/mach/rpc.mdwn    |  9 ++++++++-
 open_issues/librpci.mdwn     | 31 +++++++++++++++++++++++++++++++
 3 files changed, 48 insertions(+), 5 deletions(-)
 create mode 100644 open_issues/librpci.mdwn

(limited to 'hurd')

diff --git a/hurd/debugging/rpctrace.mdwn b/hurd/debugging/rpctrace.mdwn
index de46c08d..f7136056 100644
--- a/hurd/debugging/rpctrace.mdwn
+++ b/hurd/debugging/rpctrace.mdwn
@@ -1,13 +1,13 @@
-[[!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
 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]]."]]"""]]
 
 *rpctrace* is -- roughly -- an equivavlent to Linux's *strace* or Solaris' or
 BSD's *truss*.  It is used to trace [[remote_procedure_call|rpc]]s a process is
@@ -51,3 +51,8 @@ See `rpctrace --help` about how to use it.
          it's a while since I have dived into rpctrace; but AIUI, it should work just fine if the proxying is done properly
          note that there is a number of known bugs in rpctrace, for which zhengda has sent patches... though I haven't reviewed all of them I think
          there are some nasty Mach operations that are really hard to proxy -- but I don't think the auth mechanism needs any of these...
+
+
+# See Also
+
+See also [[open_issues/librpci]].
diff --git a/microkernel/mach/rpc.mdwn b/microkernel/mach/rpc.mdwn
index 60275a86..422e0441 100644
--- a/microkernel/mach/rpc.mdwn
+++ b/microkernel/mach/rpc.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
@@ -19,3 +19,10 @@ implementation in the kernel possible, too, which is called *NORMA*, but is not
 avilable in [[GNU Mach|gnumach]].
 
 The RPC stub code generated by [[MIG]].
+
+
+# Tracing
+
+  * [[hurd/debugging/rpctrace]]
+
+  * [[open_issues/librpci]]
diff --git a/open_issues/librpci.mdwn b/open_issues/librpci.mdwn
new file mode 100644
index 00000000..a3af16b1
--- /dev/null
+++ b/open_issues/librpci.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_gnumach open_issue_hurd]]
+
+2004 to 2007, Anand Babu has been working some on this project.  It is still in
+rather early stages.  It's meant to become an extension/complement to
+[[hurd/debugging/rpctrace]].
+
+  * 
+
+    > A C language library for interposing ports of a Hurd task running on top
+    > of GNU Mach micro-kernel. Using this library, it would be possible to
+    > implement a trace/replay system, RPC debugger, sandbox, etc.
+
+    On top of that, a debugger was planned:
+
+    > A RPC level debugger with useful command set to analyze/manipulate a task
+    > at run time. For example, the user will be able to set RPC break points,
+    > manipulate port rights and data, trace and replay a task.
+
+If there is interest, the existing source code could be moved from the CVS
+repository into the [[source_repositories/incubator]] ([[tschwinge]] already
+locally converted it to Git.)
-- 
cgit v1.2.3