diff options
Diffstat (limited to 'open_issues/linux_as_the_kernel.mdwn')
| -rw-r--r-- | open_issues/linux_as_the_kernel.mdwn | 33 |
1 files changed, 32 insertions, 1 deletions
diff --git a/open_issues/linux_as_the_kernel.mdwn b/open_issues/linux_as_the_kernel.mdwn index 1d84d777..2656b1a3 100644 --- a/open_issues/linux_as_the_kernel.mdwn +++ b/open_issues/linux_as_the_kernel.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2012 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2012, 2014 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 @@ -235,3 +235,34 @@ Richard's X-15 Mach re-implementation: <braunr> i'll have to check, it's been a long time since i've really used it <braunr> they must use a pure devfs instance now + + +# IRC, freenode, #hurd, 2014-02-23 + + <desrt> so crazy idea: would it be possible to have mach as a linux kernel + module? + <desrt> ie: some new binfmt type thing that could load mach binaries and + implement the required kernel ABI for them + <desrt> and then run the entire hurd under that.... + <braunr> desrt: that's an idea, yes + <braunr> and not a new one + * desrt did a bit of googling but didn't find any information about it + <braunr> desrt: but why are you thinking of it ? + <braunr> we talked about it here, informally + <desrt> braunr: mostly because running hurd in a VM sucks + <desrt> if we had mach-via-linux, we'd have: + <desrt> - no vm overhead + <desrt> - no device virtualisation + <desrt> - 64bit (physical at least) memory support + <desrt> - SMP + <desrt> - access to the linux drivers, natively + <desrt> and maybe some other nice things + <braunr> yes we talkbed about all this + <braunr> but i still consider that to be an incomplete solution + <desrt> i don't consider it to be running "the hurd" as your OS... but it + would be a nice solution for development and virtualisation + <braunr> we probably don't want to use drivers natively, since we want them + to run in their own address space, with their own namespace context + <braunr> it would, certainly + <braunr> but it would require a lot of effort anyway + <desrt> right |