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 multithreading and later 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

IRC, freenode, #hurd, 2013-04-13

<braunr> a microkernel loosely based on mach for a future hurd-like system
<JoshuaB> ok. no way! Are you in the process of building a micro-kernel
  that the hurd may someday run on?
<braunr> not the hurd, a hurd-like system
<JoshuaB> ok wow. sounds pretty cool, and tricky 
<braunr> the hurd could, but would require many changes too, and the point
  of this rewrite is to overcome the most difficult technical performance
  and scalability problems of the current hurd
<braunr> doing that requires deep changes in the low level interfaces
<braunr> imo, a rewrite is more appropriate
<braunr> sometimes, things done in x15 can be ported to the hurd
<braunr> but it still requires a good deal of effort