summaryrefslogtreecommitdiff
path: root/microkernel/mach/deficiencies.mdwn
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel/mach/deficiencies.mdwn')
-rw-r--r--microkernel/mach/deficiencies.mdwn66
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)