5 files changed, 59 insertions, 2 deletions
diff --git a/microkernel/mach/gnumach/debugging.mdwn b/microkernel/mach/gnumach/debugging.mdwn
index 71e92459..7e7cfb4e 100644
--- a/microkernel/mach/gnumach/debugging.mdwn
+++ b/microkernel/mach/gnumach/debugging.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -75,6 +75,9 @@ When you're [[running_a_system_in_QEMU|hurd/running/qemu]] you can directly
 kernel](http://www.nongnu.org/qemu/qemu-doc.html#SEC48).
 
 
+## [[open_issues/debugging_gnumach_startup_qemu_gdb]]
+
+
 # Code Inside the Kernel
 
 Alternatively you can use an approach like this one: add the following code
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 587178e9..32e712c9 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -105,6 +105,11 @@ These boards are known to work. Gnumach/Hurd has been installed and run on these
 * VIA EPIA-M Mini-ITX motherboard with VIA Nehemiah C3 1Ghz processor. Onboard NIC (VIA Rhine) works good.
 * Compaq Deskpro ENS, Pentium3 (666 MHz upgraded to 1 GHz), Intel i815 chipset, chipset integrated NIC (detected twice, but works fine with eth0; trying to access eth1 confuses the driver and makes the system unusable), Matrox Mystique 220 (PCI) graphics card. Also works with rtl8029 (NE2000 PCI) NIC when onboard NIC disabled in BIOS setup.
 * Abit BX6 Rev. 2.0 with Celeron 400, after disabling "memory hole at 15MB" option in BIOS setup. (Otherwise, Mach detects only 15MiB of RAM, making Hurd run *extremely* slow and instable.) Should also work with PentiumII or Pentium3.
+* IRC, freenode, #hurd, 2013-08-26:
+
+        < stargater> have anyone gnu/hurd running on real hw ? 
+        < youpi> my latitude e6420 laptop, for instance
+
 
 # User Failure Reports
 
diff --git a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn
index ca52dca5..a169e92e 100644
--- a/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn
+++ b/microkernel/mach/gnumach/interface/syscall/mach_print.mdwn
@@ -59,3 +59,32 @@ License|/fdl]]."]]"""]]
       it
 
 [[Makefile]], [[mach_print.S]], [[main.c]].
+
+
+## IRC, freenode, #hurd, 2013-07-01
+
+    <youpi> braunr: btw, we are missing the symbol in mach/Versions
+    <braunr> youpi: what symbol ?
+    <youpi> so the libc-provided RPC stub is not available
+    <youpi> mach_printf
+    <youpi> -f
+    <braunr> it's a system calll
+    <braunr> not exported
+    <youpi> s/RPC/system call/
+    <braunr> that's expected
+    <youpi> libc does provide stubs for system calls too
+    <braunr> yes but not for this one
+    <youpi> I don't see why we wouldn't want to include it
+    <youpi> ?! it does
+    <braunr> it's temporary
+    <braunr> oh
+    <braunr> there must be automatic parsing during build
+    <youpi> sure
+    <braunr> nice
+
+    <braunr> youpi: if we're going to make this system call exported by glibc,
+      i should change its interface first
+    <braunr> it was meant as a very quick-and-dirty hack and directly accesses
+      the caller's address space without going through a special copy-from-user
+      function
+    <braunr> not very portable
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 4e237269..477f0a18 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -188,3 +188,18 @@ License|/fdl]]."]]"""]]
       patch
     <braunr> (more kernel memory, thus more physical memory - up to 1.8 GiB -
       but then, less user memory)
+
+
+# IRC, freenode, #hurd, 2013-06-06
+
+    <nlightnfotis> braunr: quick question, what memory allocation algorithms
+      does the Mach use? I know it uses slab allocation, so I can guess buddy
+      allocators too?
+    <braunr> no
+    <braunr> slab allocator for kernel memory (allocation of buffers used by
+      the kernel itself)
+    <braunr> a simple freelist for physical pages
+    <braunr> and a custom allocator based on a red-black tree, a linked list
+      and a hint for virtual memory
+    <braunr> (which is practically the same in all BSD variants)
+    <braunr> and linux does something very close too
diff --git a/microkernel/mach/gnumach/ports.mdwn b/microkernel/mach/gnumach/ports.mdwn
index e7fdb446..c81cdd2a 100644
--- a/microkernel/mach/gnumach/ports.mdwn
+++ b/microkernel/mach/gnumach/ports.mdwn
@@ -1,4 +1,4 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012 Free Software
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2012, 2013 Free Software
 Foundation, Inc."]]
 
 [[!meta license="""[[!toggle id="license" text="GFDL 1.2+"]][[!toggleable
@@ -27,3 +27,8 @@ License|/fdl]]."]]"""]]
   * MIPS.  Status completely unknown.
 
   * [[open_issues/Mach_on_Top_of_POSIX]].  Status unknown.
+
+When starting a port for a new architecture, it might make sense to first
+target a [[!wikipedia desc=paravirtualized Paravirtualization]] environment,
+that already abstracts away some of the different hardware implementations'
+quirks.