diff options
author | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2011-02-20 22:19:43 +0100 |
---|---|---|
committer | Samuel Thibault <samuel.thibault@ens-lyon.org> | 2011-02-20 22:19:43 +0100 |
commit | 7dd4adb5612fa6042d421e8d436a0c7b4facfb22 (patch) | |
tree | a0ff209360084aa8de37e9b5a52db6de81103aac /open_issues/implementing_hurd_on_top_of_another_system.mdwn | |
parent | 72f22ab02e662e9e9fed6918ec145fd77584dad1 (diff) | |
parent | d22a3b299d00ce757237f9aee9794d0d4f2758e2 (diff) |
Merge branch 'master' of flubber:~hurd-web/hurd-web
Diffstat (limited to 'open_issues/implementing_hurd_on_top_of_another_system.mdwn')
-rw-r--r-- | open_issues/implementing_hurd_on_top_of_another_system.mdwn | 37 |
1 files changed, 37 insertions, 0 deletions
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... |