3 files changed, 61 insertions, 8 deletions
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:
+
+    <braunr> one ugly trick i use when printf isn't available is to halt the
+      cpu
+    <braunr> then use info registers to know where the cpu is halted
+    <braunr> and you'll know if you reached that code or not
+    <braunr> (info registers is a qemu command)
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
     <braunr> antrik: but you're right, since mach uses a direct mapped kernel
       space, the true problem is the lack of linux-like highmem support
     <braunr> which isn't required if the kernel space is really virtual
+
+
+---
+
+IRC, freenode, #hurd, 2011-06-09
+
+    <braunr> btw, how can gnumach use 1 GiB of RAM ? did you lower the
+      user/kernel boundary address ?
+    <youpi> I did
+    <braunr> 2G ?
+    <youpi> yes
+    <braunr> ok
+    <youpi> it doesn't make so much sense to let processes have 3G addressing
+      space when there can't be more that 1G physical memory
+    <braunr> that's sad for an operating system which does most things by
+      mapping memory eh
+    <youpi> well, if a process wants to map crazy things, 3G may be tight
+      already
+    <youpi> e.g. ext2fs
+    <braunr> yes
+    <youpi> so there's little point in supporting them
+    <braunr> we need hurd/amd64
+    <youpi> and there's quite some benefit in shrinking them to 2G
+    <youpi> yes
+    <youpi> actually even 2G may become a bit tight
+    <youpi> webkit linking needs about 1.5-2GiB
+    <youpi> things become really crazy
+    <braunr> wow
+    <braunr> i remember the linux support for 4G/4G split when there was enough
+      RAM to fill the kernel space with struct page entries
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
+
+    <braunr> youpi: does xen provide disk caching options ?
+    <youpi> through a blktap, probably
+    <braunr> ok