diff options
Diffstat (limited to 'microkernel/mach/deficiencies.mdwn')
| -rw-r--r-- | microkernel/mach/deficiencies.mdwn | 87 |
1 files changed, 87 insertions, 0 deletions
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn index 9ba67219..b3e1758c 100644 --- a/microkernel/mach/deficiencies.mdwn +++ b/microkernel/mach/deficiencies.mdwn @@ -528,3 +528,90 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]]. physical maps (cpu-specific page tables) for user tasks, and stack tracing (in addition to symbol resolution when symbols are available) were recently added + + +### IRC, freenode, #hurd, 2013-01-15 + + <braunr> Anarchos: as a side note, i'm currently working on a hurd clone + with a microkernel that takes a lot from mach but also completely changes + the ipc interface (making it not mach at all in the end) + <braunr> it's something between mach and qnx neutrino + <zacts> braunr: do you have a git repo of your new clone? + <braunr> http://git.sceen.net/rbraun/x15.git/ + <zacts> neat + <braunr> it's far from complete + <braunr> and hasn't reached a status where it can be publically announced + <zacts> ok + <braunr> but progress has been constant so far, the ideas i'm using have + proven applicable on other systems, i don't expect the kind of design + issues that blocked HurdNG + <braunr> (also, my attempt doesn't aim at the same goals as hurdng did) + <braunr> (e.g. denial of service remains completely possible) + <zacts> so x15 will use the current hurd translators? you are only + replacing gnumach? + <braunr> that was the plan some years ago, but now that i know the hurd + better, i think the main issues are in the hurd, so there isn't much + point rewriting mach + <braunr> so, if the hurd needs a revamp, it's better to also make the + underlying interface better if possible + <braunr> zacts: in other words: it's a completely different beast + <zacts> ok + <braunr> the main goal is to create a hurd-like system that overcomes the + current major defficiencies, most of them being caused by old design + decisions + <zacts> like async ipc? + <braunr> yes + <Anarchos> time for a persistent hurd ? :) + <braunr> no way + <braunr> i don't see a point to persistence for a general purpose system + <braunr> and it easily kills performance + <braunr> on the other hand, it would be nice to have a truely scalable, + performant, and free microkernel based system + <braunr> (and posix compatible) + <braunr> there is currently none + <braunr> zacts: the projects focuses mostly on performance and scalability, + while also being very easy to understand and maintain (something i think + the current hurd has failed at :/) + <braunr> project* + <zacts> very cool + <braunr> i think so, but we'll have to wait for an end result :) + <braunr> what's currently blocking me is the IDL + <braunr> earlier research has shown that an idl must be optmized the same + way compilers are for the best performances + <braunr> i'm not sure i can write something good enough :/ + <braunr> the first version will probably be very similar to mig, small and + unoptimized + + +### IRC, freenode, #hurd, 2013-01-18 + + <zacts> braunr: so how exactly do the goals of x15 differ from viengoos? + <braunr> zacts: viengoos is much more ambitious about the design + <braunr> tbh, i still don't clearly see how its half-sync ipc work + <braunr> x15 is much more mach-like, e.g. a hybrid microkernel with + scheduling and virtual memory in the kernel + <braunr> its goals are close to those of mach, adding increased scalability + and performance to the list + <zacts> that's neat + <braunr> that's different + <braunr> in a way, you could consider x15 is to mach what linux is to unix, + a clone with a "slightly" different interface + <zacts> ah, ok. cool! + <braunr> viengoos is rather a research project, with very interesting + goals, i think they're both neat :p + + +### IRC, freenode, #hurd, 2013-01-19 + + <braunr> for now, it provides kernel memory allocation and basic threading + <braunr> it already supports both i386 and amd64 processors (from i586 + onwards), and basic smp + <zacts> oh wow + <zacts> how easily can it be ported to other archs? + <braunr> the current focus is smp load balancing, so that thread migration + is enabled during development + <braunr> hard to say + <braunr> everything that is arch-specific is cleanly separated, the same + way it is in mach and netbsd + <braunr> but the arch-specific interfaces aren't well defined yet because + there is only one (and incomplete) arch |