summaryrefslogtreecommitdiff
path: root/microkernel
diff options
context:
space:
mode:
Diffstat (limited to 'microkernel')
-rw-r--r--microkernel/mach/deficiencies.mdwn136
1 files changed, 136 insertions, 0 deletions
diff --git a/microkernel/mach/deficiencies.mdwn b/microkernel/mach/deficiencies.mdwn
index b3e1758c..dcabb56e 100644
--- a/microkernel/mach/deficiencies.mdwn
+++ b/microkernel/mach/deficiencies.mdwn
@@ -615,3 +615,139 @@ In context of [[open_issues/multithreading]] and later [[open_issues/select]].
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
+
+
+### IRC, freenode, #hurd, 2013-03-08
+
+ <antrik> BTW, what is your current direction? did you follow through with
+ abandonning Mach resemblance?...
+ <braunr> no
+ <braunr> it's very similar to mach in many ways
+ <braunr> unless mach is defined by its ipc in which case it's not mach at
+ all
+ <braunr> the ipc interface will be similar to the qnx one
+ <antrik> well, Mach is pretty much defined by it's IPC and VM interface...
+ <braunr> the vm interface remains
+ <antrik> its
+ <braunr> although vm maps will be first class objects
+ <braunr> so that it will be possible to move parts of the vm server outside
+ the kernel some day if it feels like a good thing to do
+ <braunr> i.e. vm maps won't be inferred from tasks
+ <braunr> not implicitely
+ <braunr> the kernel will be restricted to scheduling, memory management,
+ and ipc, much as mach is (notwithstanding drivers)
+ <antrik> hm... going with QNX IPC still seems risky to me... it's designed
+ for simple embedded environments, not for general-purpose operating
+ systems in my understanding
+ <braunr> no, the qnx ipc interface is very generic
+ <braunr> they can already call remote services
+ <braunr> the system can scale well on multiprocessor machines
+ <braunr> that's not risky at all, on the contrary
+ <antrik> yeah, I'm sure it's generic... but I don't think anybody tried to
+ build a Hurd-like system on top of it; so it's not at all clear whether
+ it will work out at all...
+ <auronandace> clueless question: does x15 have any inspiration from
+ helenos?
+ <braunr> absolutely none
+ <braunr> i'd say x15 is almost an opposite to helenos
+ <braunr> it's meant as a foundation for unix systems, like mach
+ <braunr> some unix interfaces considered insane by helenos people (such as
+ fork and signals) will be implemented (although not completely in the
+ kernel)
+ <braunr> ipc will be mostly synchronous
+ <braunr> they're very different
+ <braunr> well, helenos is very different
+ <auronandace> cool
+ <braunr> x15 and actually propel (the current name i have for the final
+ system), are meant to create a hurd clone
+ <auronandace> another clueless question: any similarities of x15 to minix?
+ <braunr> and since we're few, implementing posix efficiently is a priority
+ goal for me
+ <braunr> again, absolutely none
+ <braunr> for the same reasons
+ <braunr> minix targets resilience in embedded environments
+ <braunr> propel is a hurd clone
+ <braunr> propel aims at being a very scalable and performant hurd clone
+ <braunr> that's all
+ <auronandace> neato
+ <braunr> unfortunately, i couldn't find a name retaining all the cool
+ properties of the hurd
+ <braunr> feel free to suggest ideas :)
+ <auronandace> propel? as in to launch forward?
+ <braunr> push forward, yes
+ <auronandace> that's very likely a better name than anything i could
+ conjure up
+ <braunr> x15 is named after mach (the first aircraft to break mach 4,
+ reaching a bit less than mach 7)
+ <braunr> servers will be engines, and together to push the system forward
+ ..... :)
+ <auronandace> nice
+ <auronandace> thrust might be a bit too generic i guess
+ <braunr> oh i'm looking for something like "hurd"
+ <braunr> doubly recursive acronym, related to gnu
+ <braunr> and short, so it can be used as a c namespace
+ <braunr> antrik: i've thought about it a lot, and i'm convinced this kind
+ of interface is fine for a hurd like system
+ <braunr> the various discussions i found about the hurd requirements
+ (remember roland talking about notifications) all went in this direction
+ <braunr> note however the interface isn't completely synchronous
+ <braunr> and that's very important
+ <antrik> well, I'm certainly curious. but if you are serious about this,
+ you'd better start building a prototype as soon as possible, rather than
+ perfecting SMP ;-)
+ <braunr> i'm not perfecting smp
+ <braunr> but i consider it very important to have migrations and preemption
+ actually working before starting the prototype
+ <braunr> so that tricky mistakes about concurrency can be catched early
+ <antrik> my current hunch is that you are trying to do too much at the same
+ time... improving both the implementation details and redoing the system
+ design
+ <braunr> so, for example, there is (or will be soon, actually) thread
+ migratio, but the scheduler doesn't take processor topology into account
+ <braunr> that's why i'm starting from scratch
+ <braunr> i don't delve too deep into the details
+ <braunr> just the ones i consider very important
+ <antrik> what do you mean by thread migration here? didn't you say you
+ don't even have IPC?...
+ <braunr> i mean migration between cpus
+ <antrik> OK
+ <braunr> the other is too confusing
+ <braunr> and far too unused and unknown to be used
+ <braunr> and i won't actually implement it the way it was done in mach
+ <braunr> again, it will be similar to qnx
+ <antrik> oh? now that's news for me :-)
+ <antrik> you seemed pretty hooked on thread migration when we talked about
+ these things last time...
+ <braunr> i still am
+ <braunr> i'm just saying it won't be implemented the same way
+ <braunr> instead of upcalls from the kernel into userspace, i'll "simply"
+ make server threads inherit from the caller's scheduling context
+ <braunr> the ideas i had about stack management are impossible to apply in
+ practice
+ <braunr> which make the benefit i imagined unrealistic
+ <braunr> and the whole idea was very confusing when compared and integrated
+ into a unix like view
+ <braunr> so stack usage will be increased
+ <braunr> that's ok
+ <antrik> but thread migration is more or less equivalent with first-class
+ RPCs AIUI. does that work with the QNX IPC model?...
+ <braunr> the very important property that threads don't block and wake a
+ server when sending, and the server again blocks and wake the client on
+ reply, is preserved
+ <antrik> (in fact I find the term "first-class RPC" much clearer...)
+ <braunr> i dont
+ <braunr> there are two benefits in practice: since the scheduling context
+ is inherited, the client is charged for the cpu time consumed
+ <braunr> and since there are no wakeups and blockings, but a direct hand
+ off in the scheduler, the cost of crossing task space is closer to the
+ system call
+ <antrik> which can be problematic too... but still it's the solution chosen
+ by EROS for example AIUI
+ <antrik> (inheriting scheduling contexts I mean)
+ <braunr> by practically all modern microkernel based systems actually, as
+ noted by shapiro
+ <antrik> braunr: well, both benefits can be achieved by other means as
+ well... scheduler activations like in Viengoos should handle the hand-off
+ part AIUI, and scheduling contexts can be inherited explicitly too, like
+ in EROS (and in a way in Viengoos)
+ <braunr> i don't understand viengoos well enough to do it that way