path: root/microkernel/mach/deficiencies.mdwn

[[!meta copyright="Copyright © 2012, 2013 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
document under the terms of the GNU Free Documentation License, Version 1.2 or
any later version published by the Free Software Foundation; with no Invariant
Sections, no Front-Cover Texts, and no Back-Cover Texts.  A copy of the license
is included in the section entitled [[GNU Free Documentation
License|/fdl]]."]]"""]]

[[!tag open_issue_documentation open_issue_gnumach]]


# IRC, freenode, #hurd, 2012-06-29

    <henrikcozza> I do not understand what are the deficiencies of Mach, the
      content I find on this is vague...
    <antrik> the major problems are that the IPC architecture offers poor
      performance; and that resource usage can not be properly accounted to the
      right parties
    <braunr> antrik: the more i study it, the more i think ipc isn't the
      problem when it comes to performance, not directly
    <braunr> i mean, the implementation is a bit heavy, yes, but it's fine
    <braunr> the problems are resource accounting/scheduling and still too much
      stuff inside kernel space
    <braunr> and with a very good implementation, the performance problem would
      come from crossing address spaces
    <braunr> (and even more on SMP, i've been thinking about it lately, since
      it would require syncing mmu state on each processor currently using an
      address space being modified)
    <antrik> braunr: the problem with Mach IPC is that it requires too many
      indirections to ever be performant AIUI
    <braunr> antrik: can you mention them ?
    <antrik> the semantics are generally quite complex, compared to Coyotos for
      example, or even Viengoos
    <braunr> antrik: the semantics are related to the message format, which can
      be simplified
    <braunr> i think everybody agrees on that
    <braunr> i'm more interested in the indirections
    <antrik> but then it's not Mach IPC anymore :-)
    <braunr> right
    <braunr> 22:03 < braunr> i mean, the implementation is a bit heavy, yes,
      but it's fine
    <antrik> that's not an implementation issue
    <braunr> that's what i meant by heavy :)
    <braunr> well, yes and no
    <braunr> Mach IPC have changed over time
    <braunr> it would be newer Mach IPC ... :)
    <antrik> the fact that data types are (supposed to be) transparent to the
      kernel is a major part of the concept, not just an implementation detail
    <antrik> but it's not just the message format
    <braunr> transparent ?
    <braunr> but they're not :/
    <antrik> the option to buffer in the kernel also adds a lot of complexity
    <braunr> buffer in the kernel ?
    <braunr> ah you mean message queues
    <braunr> yes
    <antrik> braunr: eh? the kernel parses all the type headers during transfer
    <braunr> yes, so it's not transparent at all
    <antrik> maybe you have a different understanding of "transparent" ;-)
    <braunr> i guess
    <antrik> I think most of the other complex semantics are kinda related to
      the in-kernel buffering...
    <braunr> i fail to see why :/
    <antrik> well, it allows ports rights to be destroyed while a message is in
      transfer. a lot of semantics revolve around what happens in that case
    <braunr> yes but it doesn't affect performance a lot
    <antrik> sure it does. it requires a lot of extra code and indirections
    <braunr> not a lot of it
    <antrik> "a lot" is quite a relative term :-)
    <antrik> compared to L4 for example, it *is* a lot
    <braunr> and those indirections (i think you refer to more branching here)
      are taken only when appropriate, and can be isolated, improved through
      locality, etc..
    <braunr> the features they add are also huge
    <braunr> L4 is clearly insufficient
    <braunr> all current L4 forks have added capabilities ..
    <braunr> (that, with the formal verification, make se4L one of the
      "hottest" recent system projects)
    <braunr> seL4*
    <antrik> yes, but with very few extra indirection I think... similar to
      EROS (which claims to have IPC almost as efficient as the original L4)
    <braunr> possibly
    <antrik> I still fail to see much real benefit in formal verification :-)
    <braunr> but compared to other problems, this added code is negligible
    <braunr> antrik: for a microkernel, me too :/
    <braunr> the kernel is already so small you can simply audit it :)
    <antrik> no, it's not neglible, if you go from say two cache lines touched
      per IPC (original L4) to dozens (Mach)
    <antrik> every additional variable that needs to be touched to resolve some
      indirection, check some condition adds significant overhead
    <braunr> if you compare the dozens to the huge amount of inter processor
      interrupt you get each time you change the kernel map, it's next to
      nothing ..
    <antrik> change the kernel map? not sure what you mean
    <braunr> syncing address spaces on hundreds of processors each time you
      send a message is a real scalability issue here (as an example), where
      Mach to L4 IPC seem like microoptimization
    <youpi> braunr: modify, you mean?
    <braunr> yes
    <youpi> (not switchp
    <youpi> )
    <braunr> but that's only one example
    <braunr> yes, modify, not switch
    <braunr> also, we could easily get rid of the ihash library
    <braunr> making the message provide the address of the object associated to
      a receive right
    <braunr> so the only real indirection is the capability, like in other
      systems, and yes, buffering adds a bit of complexity
    <braunr> there are other optimizations that could be made in mach, like
      merging structures to improve locality
    <pinotree> "locality"?
    <braunr> having rights close to their target port when there are only a few
    <braunr> pinotree: locality of reference
    <youpi> for cache efficiency
    <antrik> hundreds of processors? let's stay realistic here :-)
    <braunr> i am ..
    <braunr> a microkernel based system is also a very good environment for RCU
    <braunr> (i yet have to understand how liburcu actually works on linux)
    <antrik> I'm not interested in systems for supercomputers. and I doubt
      desktop machines will get that many independant cores any time soon. we
      still lack software that could even romotely exploit that
    <braunr> hum, the glibc build system ? :>
    <braunr> lol
    <youpi> we have done a survey over the nix linux distribution
    <youpi> quite few packages actually benefit from a lot of cores
    <youpi> and we already know them :)
    <braunr> what i'm trying to say is that, whenever i think or even measure
      system performance, both of the hurd and others, i never actually see the
      IPC as being the real performance problem
    <braunr> there are many other sources of overhead to overcome before
      getting to IPC
    <youpi> I completely agree
    <braunr> and with the advent of SMP, it's even more important to focus on
      contention
    <antrik> (also, 8 cores aren't exactly a lot...)
    <youpi> antrik: s/8/7/ , or even 6 ;)
    <antrik> braunr: it depends a lot on the use case. most of the problems we
      see in the Hurd are probably not directly related to IPC performance; but
      I pretty sure some are
    <antrik> (such as X being hardly usable with UNIX domain sockets)
    <braunr> antrik: these have more to do with the way mach blocks than IPC
      itself
    <braunr> similar to the ext2 "sleep storm"
    <antrik> a lot of overhead comes from managing ports (for for example),
      which also mostly comes down to IPC performance
    <braunr> antrik: yes, that's the main indirection
    <braunr> antrik: but you need such management, and the related semantics in
      the kernel interface
    <braunr> (although i wonder if those should be moved away from the message
      passing call)
    <antrik> you mean a different interface for kernel calls than for IPC to
      other processes? that would break transparency in a major way. not sure
      we really want that...
    <braunr> antrik: no
    <braunr> antrik: i mean calls specific to right management
    <antrik> admittedly, transparency for port management is only useful in
      special cases such as rpctrace, and that probably could be served better
      with dedicated debugging interfaces...
    <braunr> antrik: i.e. not passing rights inside messages
    <antrik> passing rights inside messages is quite essential for a capability
      system. the problem with Mach IPC in regard to that is that the message
      format allows way more flexibility than necessary in that regard...
    <braunr> antrik: right
    <braunr> antrik: i don't understand why passing rights inside messages is
      important though
    <braunr> antrik: essential even
    <youpi> braunr: I guess he means you need at least one way to pass rights
    <antrik> braunr: well, for one, you need to pass a reply port with each RPC
      request...
    <braunr> youpi: well, as he put, the message passing call is overpowered,
      and this leads to many branches in the code
    <braunr> antrik: the reply port is obvious, and can be optimized
    <braunr> antrik: but the case i worry about is passing references to
      objects between tasks
    <braunr> antrik: rights and identities with the auth server for example
    <braunr> antrik: well ok forget it, i just recall how it actually works :)
    <braunr> antrik: don't forget we lack thread migration
    <braunr> antrik: you may not think it's important, but to me, it's a major
      improvement for RPC performance
    <antrik> braunr: how can seL4 be the most interesting microkernel
      then?... ;-)
    <braunr> antrik: hm i don't know the details, but if it lacks thread
      migration, something is wrong :p
    <braunr> antrik: they should work on viengoos :)
    <antrik> (BTW, AIUI thread migration is quite related to passive objects --
      something Hurd folks never dared seriously consider...)
    <braunr> i still don't know what passive objects are, or i have forgotten
      it :/
    <antrik> no own control threads
    <braunr> hm, i'm still missing something
    <braunr> what do you refer to by control thread ?
    <braunr> with*
    <antrik> i.e. no main loop etc.; only activated by incoming calls
    <braunr> ok
    <braunr> well, if i'm right, thomas bushnel himself wrote (recently) that
      the ext2 "sleep" performance issue was expected to be solved with thread
      migration
    <braunr> so i guess they definitely considered having it
    <antrik> braunr: don't know what the "sleep peformance issue" is...
    <braunr> http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00032.html
    <braunr> antrik: also, the last message in the thread,
      http://lists.gnu.org/archive/html/bug-hurd/2011-12/msg00050.html
    <braunr> antrik: do you consider having a reply port being an avoidable
      overhead ?
    <antrik> braunr: not sure. I don't remember hearing of any capability
      system doing this kind of optimisation though; so I guess there are
      reasons for that...
    <braunr> antrik: yes me too, even more since neal talked about it on
      viengoos
    <antrik> I wonder whether thread management is also such a large overhead
      with fully sync IPC, on L4 or EROS for example...
    <braunr> antrik: it's still a very handy optimization for thread scheduling
    <braunr> antrik: it makes solving priority inversions a lot easier
    <antrik> actually, is thread scheduling a problem at all with a thread
      activation approach like in Viengoos?
    <braunr> antrik: thread activation is part of thread migration
    <braunr> antrik: actually, i'd say they both refer to the same thing
    <antrik> err... scheduler activation was the term I wanted to use
    <braunr> same
    <braunr> well
    <braunr> scheduler activation is too vague to assert that
    <braunr> antrik: do you refer to scheduler activations as described in
      http://en.wikipedia.org/wiki/Scheduler_activations ?
    <antrik> my understanding was that Viengoos still has traditional threads;
      they just can get scheduled directly on incoming IPC
    <antrik> braunr: that Wikipedia article is strange. it seems to use
      "scheduler activations" as a synonym for N:M multithreading, which is not
      at all how I understood it
    <youpi> antrik: I used to try to keep a look at those pages, to fix such
      wrong things, but left it
    <braunr> antrik: that's why i ask
    <antrik> IIRC Viengoos has a thread associated with each receive
      buffer. after copying the message, the kernel would activate the
      processes activation handler, which in turn could decide to directly
      schedule the thead associated with the buffer
    <antrik> or something along these lines
    <braunr> antrik: that's similar to mach handoff
    <youpi> antrik: generally enough, all the thread-related pages on wikipedia
      are quite bogus
    <antrik> nah, handoff just schedules the process; which is not useful, if
      the right thread isn't activated in turn...
    <braunr> antrik: but i think it's more than that, even in viengoos
    <youpi> for instance, the french "thread" page was basically saying that
      they were invented for GUIs to overlap computation with user interaction
    <braunr> .. :)
    <antrik> youpi: good to know...
    <braunr> antrik: the "misunderstanding" comes from the fact that scheduler
      activations is the way N:M threading was implemented on netbsd
    <antrik> youpi: that's a refreshing take on the matter... ;-)
    <braunr> antrik: i'll read the critique and viengoos doc/source again to be
      sure about what we're talking :)
    <braunr> antrik: as threading is a major issue in mach, and one of the
      things i completely changed (and intend to change) in x15, whenever i get
      to work on that again ..... :)
    <braunr> antrik: interestingly, the paper about scheduler activations was
      written (among others) by brian bershad, in 92, when he was actively
      working on research around mach
    <antrik> braunr: BTW, I have little doubt that making RPC first-class would
      solve a number of problems... I just wonder how many others it would open


# IRC, freenode, #hurd, 2012-09-04

X15

    <braunr> it was intended as a mach clone, but now that i have better
      knowledge of both mach and the hurd, i don't want to retain mach
      compatibility
    <braunr> and unlike viengoos, it's not really experimental
    <braunr> it's focused on memory and cpu scalability, and performance, with
      techniques likes thread migration and rcu
    <braunr> the design i have in mind is closer to what exists today, with
      strong emphasis on scalability and performance, that's all
    <braunr> and the reason the hurd can't be modified first is that my design
      relies on some important design changes
    <braunr> so there is a strong dependency on these mechanisms that requires
      the kernel to exists first


## IRC, freenode, #hurd, 2012-09-06

In context of [[open_issues/multithreading]] and later [[open_issues/select]].

    <gnu_srs> And you will address the design flaws or implementation faults
      with x15?
    <braunr> no
    <braunr> i'll address the implementation details :p
    <braunr> and some design issues like cpu and memory resource accounting 
    <braunr> but i won't implement generic resource containers
    <braunr> assuming it's completed, my work should provide a hurd system on
      par with modern monolithic systems
    <braunr> (less performant of course, but performant, scalable, and with
      about the same kinds of problems)
    <braunr> for example, thread migration should be mandatory
    <braunr> which would make client calls behave exactly like a userspace task
      asking a service from the kernel
    <braunr> you have to realize that, on a monolithic kernel, applications are
      clients, and the kernel is a server
    <braunr> and when performing a system call, the calling thread actually
      services itself by running kernel code
    <braunr> which is exactly what thread migration is for a multiserver system
    <braunr> thread migration also implies sync IPC
    <braunr> and sync IPC is inherently more performant because it only
      requires one copy, no in kernel buffering
    <braunr> sync ipc also avoids message floods, since client threads must run
      server code
    <gnu_srs> and this is not achievable with evolved gnumach and/or hurd?
    <braunr> well that's not entirely true, because there is still a form of
      async ipc, but it's a lot less likely
    <braunr> it probably is
    <braunr> but there are so many things to change i prefer starting from
      scratch
    <braunr> scalability itself probably requires a revamp of the hurd core
      libraries
    <braunr> and these libraries are like more than half of the hurd code
    <braunr> mach ipc and vm are also very complicated
    <braunr> it's better to get something new and simpler from the start
    <gnu_srs> a major task nevertheless:-D
    <braunr> at least with the vm, netbsd showed it's easier to achieve good
      results from new code, as other mach vm based systems like freebsd
      struggled to get as good
    <braunr> well yes
    <braunr> but at least it's not experimental
    <braunr> everything i want to implement already exists, and is tested on
      production systems
    <braunr> it's just time to assemble those ideas and components together
      into something that works
    <braunr> you could see it as a qnx-like system with thread migration, the
      global architecture of the hurd, and some improvements from linux like
      rcu :)


### IRC, freenode, #hurd, 2012-09-07

    <antrik> braunr: thread migration is tested on production systems?
    <antrik> BTW, I don't think that generally increasing the priority of
      servers is a good idea
    <antrik> in most cases, IPC should actually be sync. slpz looked at it at
      some point, and concluded that the implementation actually has a
      fast-path for that case. I wonder what happens to scheduling in this case
      -- is the receiver sheduled immediately? if not, that's something to
      fix...
    <braunr> antrik: qnx does something very close to thread migration, yes
    <braunr> antrik: i agree increasing the priority isn't a good thing, but
      it's the best of the quick and dirty ways to reduce message floods
    <braunr> the problem isn't sync ipc in mach
    <braunr> the problem is the notifications (in our cases the dead name
      notifications) that are by nature async
    <braunr> and a malicious program could send whatever it wants at the
      fastest rate it can
    <antrik> braunr: malicious programs can do any number of DOS attacks on the
      Hurd; I don't see how increasing priority of system servers is relevant
      in that context
    <antrik> (BTW, I don't think dead name notifications are async by
      nature... just like for most other IPC, the *usual* case is that a server
      thread is actively waiting for the message when it's generated)
    <braunr> antrik: it's async with respect to the client
    <braunr> antrik: and malicious programs shouldn't be able to do that kind
      of dos
    <braunr> but this won't be fixed any time soon
    <braunr> on the other hand, a higher priority helps servers not create too
      many threads because of notifications, and that's a good thing
    <braunr> gnu_srs: the "fix" for this will be to rewrite select so that it's
      synchronous btw
    <braunr> replacing dead name notifications with something like cancelling a
      previously installed select request
    <antrik> no idea what "async with respect to the client" means
    <braunr> it means the client doesn't wait for anything
    <antrik> what is the client? what scenario are you talking about? how does
      it affect scheduling?
    <braunr> for notifications, it's usually the kernel
    <braunr> it doesn't directly affect scheduling
    <braunr> it affects the amount of messages a hurd server has to take care
      of
    <braunr> and the more messages, the more threads
    <braunr> i'm talking about event loops
    <braunr> and non blocking (or very short) selects
    <antrik> the amount of messages is always the same. the question is whether
      they can be handled before more come in. which would be the case if be
      default the receiver gets scheduled as soon as a message is sent...
    <braunr> no
    <braunr> scheduling handoff doesn't imply the thread will be ready to
      service the next message by the time a client sends a new one
    <braunr> the rate at which a message queue gets filled has nothing to do
      with scheduling handoff
    <antrik> I very much doubt rates come into play at all
    <braunr> well they do
    <antrik> in my understanding the problem is that a lot of messages are sent
      before the receive ever has a chance to handle them. so no matter how
      fast the receiver is, it looses
    <braunr> a lot of non blocking selects means a lot of reply ports
      destroyed, a lot of dead name notifications, and what i call message
      floods at server side
    <braunr> no
    <braunr> it used to work fine with cthreads
    <braunr> it doesn't any more with pthreads because pthreads are slightly
      slower
    <antrik> if the receiver gets a chance to do some work each time a message
      arrives, in most cases it would be free to service the next request with
      the same thread
    <braunr> no, because that thread won't have finished soon enough
    <antrik> no, it *never* worked fine. it might have been slighly less
      terrible.
    <braunr> ok it didn't work fine, it worked ok
    <braunr> it's entirely a matter of rate here
    <braunr> and that's the big problem, because it shouldn't
    <antrik> I'm pretty sure the thread would finish before the time slice ends
      in almost all cases
    <braunr> no
    <braunr> too much contention
    <braunr> and in addition locking a contended spin lock depresses priority
    <braunr> so servers really waste a lot of time because of that
    <antrik> I doubt contention would be a problem if the server gets a chance
      to handle each request before 100 others come in
    <braunr> i don't see how this is related
    <braunr> handling a request doesn't mean entirely processing it
    <braunr> there is *no* relation between handoff and the rate of incoming
      message rate
    <braunr> unless you assume threads can always complete their task in some
      fixed and low duration
    <antrik> sure there is. we are talking about a single-processor system
      here.
    <braunr> which is definitely not the case
    <braunr> i don't see what it changes
    <antrik> I'm pretty sure notifications can generally be handled in a very
      short time
    <braunr> if the server thread is scheduled as soon as it gets a message, it
      can also get preempted by the kernel before replying
    <braunr> no, notifications can actually be very long
    <braunr> hurd_thread_cancel calls condition_broadcast
    <braunr> so if there are a lot of threads on that ..
    <braunr> (this is one of the optimizations i have in mind for pthreads,
      since it's possible to precisely select the target thread with a doubly
      linked list)
    <braunr> but even if that's the case, there is no guarantee
    <braunr> you can't assume it will be "quick enough"
    <antrik> there is no guarantee. but I'm pretty sure it will be "quick
      enough" in the vast majority of cases. which is all it needs.
    <braunr> ok
    <braunr> that's also the idea behind raising server priorities
    <antrik> braunr: so you are saying the storms are all caused by select(),
      and once this is fixed, the problem should be mostly gone and the
      workaround not necessary anymore?
    <braunr> yes
    <antrik> let's hope you are right :-)
    <braunr> :)
    <antrik> (I still think though that making hand-off scheduling default is
      the right thing to do, and would improve performance in general...)
    <braunr> sure
    <braunr> well
    <braunr> no it's just a hack ;p
    <braunr> but it's a right one
    <braunr> the right thing to do is a lot more complicated
    <braunr> as roland wrote a long time ago, the hurd doesn't need dead-name
      notifications, or any notification other than the no-sender (which can be
      replaced by a synchronous close on fd like operation)
    <antrik> well, yes... I still think the viengoos approach is promising. I
      meant the right thing to do in the existing context ;-)
    <braunr> better than this priority hack
    <antrik> oh? you happen to have a link? never heard of that...
    <braunr> i didn't want to do it initially, even resorting to priority
      depression on trhead creation to work around the problem
    <braunr> hm maybe it wasn't him, i can't manage to find it
    <braunr> antrik:
      http://lists.gnu.org/archive/html/l4-hurd/2003-09/msg00009.html
    <braunr> "Long ago, in specifying the constraints of
    <braunr> what the Hurd needs from an underlying IPC system/object model we
      made it
    <braunr> very clear that we only need no-senders notifications for object
    <braunr> implementors (servers)"
    <braunr> "We don't in general make use of dead-name notifications,
    <braunr> which are the general kind of object death notification Mach
      provides and
    <braunr> what serves as task death notification."
    <braunr> "In the places we do, it's to serve
    <braunr> some particular quirky need (and mostly those are side effects of
      Mach's
    <braunr> decouplable RPCs) and not a semantic model we insist on having."


### IRC, freenode, #hurd, 2012-09-08

    <antrik> The notion that seemed appropriate when we thought about these
      issues for
    <antrik> Fluke was that the "alert" facility be a feature of the IPC system
      itself
    <antrik> rather than another layer like the Hurd's io_interrupt protocol.
    <antrik> braunr: funny, that's *exactly* what I was thinking when looking
      at the io_interrupt mess :-)
    <antrik> (and what ultimately convinced me that the Hurd could be much more
      elegant with a custom-tailored kernel rather than building around Mach)


## IRC, freenode, #hurd, 2012-09-24

    <braunr> my initial attempt was a mach clone
    <braunr> but now i want a mach-like kernel, without compability
    <lisporu> which new licence ?
    <braunr> and some very important changes like sync ipc
    <braunr> gplv3
    <braunr> (or later)
    <lisporu> cool 8)
    <braunr> yes it is gplv2+ since i didn't take the time to read gplv3, but
      now that i have, i can't use anything else for such a project: )
    <lisporu> what is mach-like ? (how it is different from Pistachio like ?) 
    <braunr> l4 doesn't provide capabilities
    <lisporu> hmmm..
    <braunr> you need a userspace for that
    <braunr> +server
    <braunr> and it relies on complete external memory management
    <lisporu> how much work is done ?
    <braunr> my kernel will provide capabilities, similar to mach ports, but
      simpler (less overhead)
    <braunr> i want the primitives right
    <braunr> like multiprocessor, synchronization, virtual memory, etc..


### IRC, freenode, #hurd, 2012-09-30

    <braunr> for those interested, x15 is now a project of its own, with no
      gnumach compability goal, and covered by gplv3+


### IRC, freenode, #hurd, 2012-12-31

    <braunr> bits of news about x15: it can now create tasks, threads, vm_maps,
      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


### 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