IRC bits.

2 files changed, 169 insertions, 4 deletions

diff --git a/microkernel/viengoos/documentation.mdwn b/microkernel/viengoos/documentation.mdwn
index 52ff7a48..edcc79a7 100644
--- a/microkernel/viengoos/documentation.mdwn
+++ b/microkernel/viengoos/documentation.mdwn
@@ -1,12 +1,12 @@
-[[!meta copyright="Copyright © 2008 Free Software Foundation, Inc."]]
+[[!meta copyright="Copyright © 2008, 2012 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]]."]]"""]]
+is included in the section entitled [[GNU Free Documentation
+License|/fdl]]."]]"""]]
 
 The most up-to-date documentation is in the source code itself, see in
 particular the header files in the hurd directory.
@@ -17,7 +17,8 @@ version of that is available [[here|reference-guide.pdf]].  It is
 not, however, automatically regenerated, and thus may not be up to
 date.
 
-Academic Papers:
+
+# Academic Papers
 
   * [Viengoos: A Framework for Stakeholder-Directed Resource
     Allocation](http://walfield.org/papers/2009-walfield-viengoos-a-framework-for-stakeholder-directed-resource-allocation.pdf).
@@ -54,3 +55,8 @@ Academic Papers:
     argue that only a small static number of scheduling policies are
     needed in practice and advocate hierarchical policy specification and
     central realization.
+
+
+# Miscellaneous
+
+  * [[IRC_2012-02-23]]
diff --git a/microkernel/viengoos/documentation/irc_2012-02-23.mdwn b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn
new file mode 100644
index 00000000..a3229be9
--- /dev/null
+++ b/microkernel/viengoos/documentation/irc_2012-02-23.mdwn
@@ -0,0 +1,159 @@
+[[!meta copyright="Copyright © 2012 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]]."]]"""]]
+
+[[!meta title="IRC, freenode, #hurd, 2012-02-23"]]
+
+[[!tag open_issue_documentation open_issue_viengoos]]
+
+    <braunr> neal: i've read a bit about current modern microkernel based
+      systems, and i'm wondering
+    <braunr> neal: can a capability be used for both request and replies, or
+      does messaging need something similar to reply ports ?
+    <neal> braunr: you want a reply port
+    <neal> think about a file server:
+    <neal> the file server publishes a capability to access something
+    <neal> and multiple entities use it
+    <neal> if you wanted just bidirectional caps
+    <braunr> that's the idea i had in mind, i just wondered if it was actually
+      still the case in practice
+    <neal> you'd need to create a new capability every time you delegated the
+      cap
+    <braunr> yes
+    <braunr> thanks
+    <braunr> what about send once rights ?
+    <neal> also, if you send on a cap and then start waiting on it you could
+      get your own reply :)
+    <neal> you can get around send-once rights by using a counter
+    <braunr> no i mean, is their behaviour still needed/useful ?
+    <neal> the counter is kernel implemented
+    <neal> yes
+    <neal> as an optimization
+    <braunr> so they're just a special case of capability
+    <neal> yes
+    <braunr> not a special capability type of their own
+    <neal> but they eliminate the constant create/destroy sequence
+    <braunr> (even if it was already the case at the implementation level in
+      mach, they were named separately which could confuse people)
+    <braunr> hm
+    <braunr> actually, send once rights were used for important notifications
+      such as dead port notifications
+    <braunr> is this still handled at the kernel level in modern ukernels ?
+    <neal> in viengoos, this is called the version field
+    <neal> see chapter 2
+    <neal>
+      http://www.gnu.org/software/hurd/microkernel/viengoos/documentation/reference-guide.pdf
+    <braunr> neal: btw, congratulations for viengoos, it really is a very
+      interesting project: )
+    <neal> thanks
+    <braunr> i don't see the point of rewriting a mach clone after reading
+      about it eh
+    <neal> I would definately do the messenger concept again
+    <neal> but I'd not do persistence
+    <braunr> i don't fully understand how messengers deal with blocking
+    <neal> did you read chapter 4?
+    <braunr> i read all of it but didn't understand everything :)
+    <braunr> it's quite abstract and i didn't make time to read some of the
+      source code
+    <neal> If you have specific questions, I can try to help
+    <braunr> i'll read those chapter again and formulate my questions after
+    <neal> I may have to read them as well :)
+    <braunr> i don't understand how you manage to separate IPC from threading
+      actually
+    <braunr> are messengers queues ?
+    <neal> messengers are super-buffers
+    <neal> they contain a reference to a thread object
+    <neal> to send a message, I use a messenger
+    <neal> I put the data in a buffer
+    <neal> and then I attach the messenger to the target messenger
+    <antrik> braunr: my stance is that we should try to incorporate the ideas
+      from Viengoos into Mach in an evolutionary process...
+    <neal> this causes an activation to be sent to the target messenger's
+      thread object
+    <braunr> neal: which activation ?
+    <neal> an activation is like a CPU interrupt
+    <braunr> neal: is it "allocated" at that moment, or taken from the sending
+      thread ?
+    <braunr> (i'm not sure my question really makes sense to you :/)
+    <antrik> braunr: not sure what you are asking exactly; but the basic idea
+      is that the receiving process preallocates message buffers
+    <braunr> antrik: maybe, i'm not sure
+    <antrik> when someone sends a message, it's stored in one of these buffers,
+      and the process gets a scheduler activation, so it can decide what to do
+      with it
+    <neal> antrik is right
+    <neal> the traget messenger designates a memory buffer
+    <braunr> i'm wondering about the details of this activation
+    <braunr> is it similar to thread migration ?
+    <neal> just before the activation, the data is copied to the messenger's
+      buffer
+    <neal> now someone needs to be notified
+    <neal> (that a message arrived)
+    <neal> that someone is the thread designated in the target messenger's
+      thread field
+    <neal> this is done by an activation
+    <neal> an activation is just an upcall
+    <neal> a thread is forced to a particular IP
+    <neal> an activation isn't a "what" it's a "how"
+    <neal> I never understood thread migration
+    <neal> as it's not really about threads
+    <neal> nor it is about migration
+    <antrik> neal: what happens if another message comes in before the
+      activation handling tread is done with the previous one?...
+    <neal> the messenger is enqueued on the thread object
+    <neal> it is delivered when the thread is in normal mode
+    <neal> part of delivering an activation is putting the thread is activation
+      mode
+    <neal> when in activation mode, it can't receive any activations
+    <braunr> i see
+    <braunr> but then, when a thread receives an activation, does it handle
+      several queued messengers at once (not to loose events/messages) ?
+    <neal> (unless it does a blocking receive on a particular messenger, which
+      is necessary to support memory allocation in activated mode)
+    <neal> it handles one at a time
+    <braunr> ah right
+    <neal> it can't lose events
+    <braunr> activations are sent per messengers/events
+    <neal> well, it can
+    <neal> but it is possible to prevent this
+    <braunr> neal: also, is message passing completely atomic ?
+    <neal> I'm not sure what you mean
+    <neal> which part
+    <braunr> well, all parts of a message :)
+    <braunr> in mach, a message can contain several parts
+    <braunr> data, rights, passing one of them may fail
+    <braunr> only the header is atomically processed
+    <neal> it's not atomic in the sense that a thread can observe the data copy
+    <braunr> that's not what i meant
+    <braunr> is a message completely transferred or not at all in case of
+      failure ?
+    <neal> it may be partially transferred
+    <braunr> or can it be partially transferred
+    <braunr> ok
+    <neal> for instance, if the target thread doesn't provide a memory buffer
+    <neal> then the data can't be copied
+    <neal> I don't recall off hand how I dealt with bad addresses
+    <neal> may be it is not possible
+    <neal> I don't remember
+    <neal> sorry
+    <braunr> but if i read the message structure correctly, there can be one
+      data block, and several capability addresses in a single message, right ?
+    <neal> yes
+    <braunr> ok
+    <braunr> have you considered passing only one object (either data or
+      capability) per message ?
+    <braunr> or is it too inefficient ?
+    <neal> you at least need a reply port
+    <neal> s/port/messenger/
+    <braunr> yes but can't it be passed separately ?
+    <neal> then you have server state
+    <neal> ik
+    <braunr> hm yes
+    <braunr> thanks for your answers: )
+    <neal> no problem