Merge remote-tracking branch 'fp/master'

Conflicts:
	open_issues/secure_file_descriptor_handling.mdwn

1 files changed, 66 insertions, 0 deletions

diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index 03e4a8b0..8f47f61f 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -2318,3 +2318,69 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
       about them
     <braunr> even with that, it should be scalable enough for a start
     <braunr> and improving those parts shouldn't be too difficult
+
+
+## IRC, freenode, #hurd, 2013-07-10
+
+    <nlightnfotis> braunr: From what I have understood you aim for x15 to be a
+      production ready μ-kernel for usage in the Hurd? Or is it unrelated to
+      the Hurd?
+    <braunr> nlightnfotis: it's for a hurd clone
+    <nlightnfotis> braunr: I see. Is it close to any of the existing
+      microkernels as far as its design is concerned (L4, Viengoos) or is it
+      new research? 
+    <braunr> it's close to mach
+    <braunr> and qnx
+
+
+## IRC, freenode, #hurd, 2013-07-29
+
+    <braunr> making progress on x15 pmap module
+    <braunr> factoring code for mapping creation/removal on current/kernel and
+      remote processes
+    <braunr> also started "swap emulation" by reserving some physical memory to
+      act as swap backing store
+    <braunr> which will allow creating memory pressure very early in the
+      development process
+
+
+## IRC, freenode, #hurd, 2013-08-23
+
+    < nlightnfotis> braunr: something a little bit irrelevant: how many things
+      are missing from mach to be considered a solid base for the Hurd? Is it
+      only SMP and x86_64 support?
+    < braunr> define "solid base for the hurd"
+    < nlightnfotis> solid enough to not look for a replacement for it
+    < braunr> then i'd say, from my very personal point of view, that you want
+      x15
+    < nlightnfotis> I didn't understand this. Are you planning for x15 to be a
+      better mach?
+    < braunr> with a different interface, so not compatible
+    < braunr> and thus, not mach
+    < nlightnfotis> is the source code for it available? Can I read it
+      somewhere?
+    < braunr> the implied answer being: no, mach isn't a solid base for the
+      hurd considering your definition
+    < braunr> http://git.sceen.net/rbraun/x15.git/
+    < nlightnfotis> thanks. for that. So it's definite that mach won't stay for
+      long as the Hurd's base, right?
+    < braunr> it will, for long
+    < braunr> my opinion is that it needs to be replaced
+    < nlightnfotis> is it possible that it (slowly) gets rearchitected into
+      what's being considered a second generation microkernel, or is it
+      hopeless?
+    < braunr> it would require a new interface
+    < braunr> you can consider x15 to be a modern mach, with that new interface
+    < braunr> from a high level view, it's very similar (it's a hybrid, with
+      both scheduling and virtual memory management in the kernel)
+    < braunr> ipc change a lot
+
+
+## IRC, freenode, #hurd, 2013-09-23
+
+    <braunr> for those of us interested in x15 and scalability in general:
+      http://darnassus.sceen.net/~rbraun/radixvm_scalable_address_spaces_for_multithreaded_applications.pdf
+    <braunr> finally an implementation allowing memory mapping to occur
+      concurrently
+    <braunr> (which is another contention issue when using mach-like ipc, which
+      often do need to allocate/release virtual memory)