IRC.

4 files changed, 97 insertions, 2 deletions

diff --git a/microkernel/mach/gnumach/continuation.mdwn b/microkernel/mach/gnumach/continuation.mdwn
new file mode 100644
index 00000000..cdd942b7
--- /dev/null
+++ b/microkernel/mach/gnumach/continuation.mdwn
@@ -0,0 +1,26 @@
+[[!meta copyright="Copyright © 2010, 2012, 2013 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]]
+
+[[Mach]] internally uses *[[/continuation]]*s for kernel [[thread]] management.
+
+The advantage is that not a full kernel thread stack has to be preserved in
+case that a thread is about to enter a blocking state.  This saves space.  It
+is not clear this is still worthwhile given today's RAM offerings.  (How many
+kernel threads are there, typically?)
+
+And, this would no longer be possible in case Mach were be made a
+[[preemptive|preemption]] kernel.  In the latter case, the kernel itself, that
+is, kernel threads can be preempted, and then their full state needs to be
+preserved.
+
+See also [[open_issues/multithreading]].
diff --git a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
index 874f5f07..3a4f560c 100644
--- a/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
+++ b/microkernel/mach/gnumach/hardware_compatibility_list.mdwn
@@ -1,5 +1,5 @@
-[[!meta copyright="Copyright © 2007, 2008, 2009, 2011 Free Software Foundation,
-Inc."]]
+[[!meta copyright="Copyright © 2007, 2008, 2009, 2011, 2013 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
@@ -91,6 +91,11 @@ Configuration](http://www.gnu.org/software/hurd/gnumach-doc/Configuration.html)
 contains a list of device drivers that are included in GNU Mach and elaborates
 on the hardware devices they support.
 
+## DDE
+
+[[hurd/DDE]] provides more up-to-date network device drivers, based on Linux
+2.6.29 code, running as user-space processes.
+
 # User Success Reports
 
 These boards are known to work. Gnumach/Hurd has been installed and run on these board successfully. 
diff --git a/microkernel/mach/gnumach/memory_management.mdwn b/microkernel/mach/gnumach/memory_management.mdwn
index 3e158b7c..a1d9a99d 100644
--- a/microkernel/mach/gnumach/memory_management.mdwn
+++ b/microkernel/mach/gnumach/memory_management.mdwn
@@ -133,3 +133,47 @@ License|/fdl]]."]]"""]]
     <braunr> using sysenter/sysexit makes it even faster
 
 [[open_issues/system_call_mechanism]].
+
+
+# IRC, freenode, #hurd, 2012-12-12
+
+    <braunr> youpi: is the 2g split patch really needed ?
+    <braunr> or rather, is it really a good thing for most people ?
+    <braunr> instead of the common 3g/1g
+    <braunr> it reduces tasks' address space but allows the kernel to reference
+      more physical memory
+    <braunr> the thing is, because of the current page cache implementation,
+      most of the time, this physical memory remains unused, or very rarely
+    <youpi> ?
+    <braunr> on the other hand, a larger address space for tasks allows running
+      more threads (more space for tasks) and not failing while linking webkit
+      .. :)
+    <youpi> it's needed for quite a few compilations, yes
+    <braunr> if you refer to the link stage, with a decent amount of swap, it
+      goes without trouble
+    <youpi> well, if your kernel doesn't have 2GiB physical addressing
+      capacity, userspace won't have >2GiB memory capacity either
+    <youpi> does it now?
+    <youpi> it didn't use to
+    <youpi> and it was crawling like hell for some builds
+    <youpi> (until simply hanging)
+    <braunr> i never have a problem e.g. runing the big malloc glibc test
+    <braunr> (bug22 or something like that)
+    <youpi> that doesn't involve objects from the fs, does it?
+    <braunr> no
+    <braunr> as long as it's anonymous memory, it's ok
+    <braunr> the default pager looks safe, i'm pretty sure our lockups are
+      because of something in ext2fs
+    <youpi> braunr: well, an alternative would be to build two kernels, one 2/2
+      and one 3/1
+    <braunr> not really worth it
+    <braunr> i was just wondering
+    <braunr> i usually prefer a 3/1 on darnassus, but i don't build as often as
+      a buildd :x
+    <youpi> or we can go with 2.5/1.5
+    <youpi> I can do that on bach & mozart for instance
+    <youpi> (they have their own kernel anyway)
+    <braunr> youpi: if you think it's worth the effort
+    <braunr> again, i was just wondering out loud
+    <youpi> braunr: well, bach & mozart don't have > 1.2GiB mem anyway
+    <youpi> so it doesn't pose problem
diff --git a/microkernel/mach/gnumach/preemption.mdwn b/microkernel/mach/gnumach/preemption.mdwn
new file mode 100644
index 00000000..520f7bc9
--- /dev/null
+++ b/microkernel/mach/gnumach/preemption.mdwn
@@ -0,0 +1,20 @@
+[[!meta copyright="Copyright © 2010, 2012, 2013 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]]
+
+There currently is no kernel preemption in GNU Mach.
+
+If GNU Mach were made a a preemptive kernel, using [[continuation]]s would
+probably no longer make sense as the kernel itself, that is, kernel threads can
+be preempted, and then their full state needs to be preserved.
+
+See also [[open_issues/multithreading]].