From 5b1145432bd23441a6ec28cc66410d679b1ebcef Mon Sep 17 00:00:00 2001
From: Thomas Schwinge <thomas@schwinge.name>
Date: Mon, 14 Feb 2011 16:54:43 +0100
Subject: open_issues/implementing_hurd_on_top_of_another_system: 2011-02-11
 IRC discussion.

---
 ...implementing_hurd_on_top_of_another_system.mdwn | 37 ++++++++++++++++++++++
 1 file changed, 37 insertions(+)

(limited to 'open_issues')

diff --git a/open_issues/implementing_hurd_on_top_of_another_system.mdwn b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
index 23512aa9..95b71ebb 100644
--- a/open_issues/implementing_hurd_on_top_of_another_system.mdwn
+++ b/open_issues/implementing_hurd_on_top_of_another_system.mdwn
@@ -78,3 +78,40 @@ IRC, #hurd, 2010-12-28
     <antrik> though I must say that I'm more and more convinced running the
       Hurd on top of a monolithic kernel would actually be a useful approach
       for the time being...
+
+---
+
+IRC, #hurd, 2011-02-11
+
+    <neal> marcus and I were discussing how to add Mach to Linux
+    <neal> one could write a module to implement Mach IPC
+    <neal> and another to implement Mach VM
+    <neal> the big thing missing with Mach VM is the ability for a tracing
+      process to easily map or unmap an inferior process's memory
+    <antrik> neal: why would a tracing process need to map the inferior's
+      memory?
+    <neal> the simple answer is that is how it is done on Mach
+    <antrik> neal: is it? not sure we are talking about the same thing
+      here. GDB uses vm_read()/vm_write() to access the inferior's memory AFAIK
+    <neal> on linux?
+    <neal> I think it use /proc/pid/mem
+    <antrik> on Hurd
+    <neal> I'm talking about adding Mach to Linux
+    <neal> by adding some functionality to Linux
+    <neal> and then implementing a bunch in user space
+    <antrik> yeah, but I don't understand the point about mapping inferior's
+      memory :-(
+    <antrik> what would be in user space?
+    <neal> there are a number of different cut points
+    <neal> one could imagine just using Linux's device drivers, CPU scheduler,
+      memory management, etc.
+    <neal> another possibility would be something higher where Hurd processes
+      just use some Hurdish servers
+    <antrik> neal: yeah, these are all options I have been considering... too
+      bad I wasn't able to come to FOSDEM -- I'd love to have participated in
+      this discussion :-(
+    <antrik> neal: BTW, were you just discussing this as a hypothetical idea,
+      or something you are seriously considering?
+    <neal> I'm unlikely to work on it, sorry
+    <antrik> didn't really expect that :-)
+    <antrik> would be nice though if you could write up your conclusions...
-- 
cgit v1.2.3