From 3bf27c93ac4de57623809b71517116d51465f0e1 Mon Sep 17 00:00:00 2001 From: Thomas Schwinge Date: Sat, 17 Mar 2012 12:31:07 +0100 Subject: IRC bits. --- .../viengoos/documentation/irc_2012-02-23.mdwn | 159 +++++++++++++++++++++ 1 file changed, 159 insertions(+) create mode 100644 microkernel/viengoos/documentation/irc_2012-02-23.mdwn (limited to 'microkernel/viengoos/documentation') 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]] + + neal: i've read a bit about current modern microkernel based + systems, and i'm wondering + neal: can a capability be used for both request and replies, or + does messaging need something similar to reply ports ? + braunr: you want a reply port + think about a file server: + the file server publishes a capability to access something + and multiple entities use it + if you wanted just bidirectional caps + that's the idea i had in mind, i just wondered if it was actually + still the case in practice + you'd need to create a new capability every time you delegated the + cap + yes + thanks + what about send once rights ? + also, if you send on a cap and then start waiting on it you could + get your own reply :) + you can get around send-once rights by using a counter + no i mean, is their behaviour still needed/useful ? + the counter is kernel implemented + yes + as an optimization + so they're just a special case of capability + yes + not a special capability type of their own + but they eliminate the constant create/destroy sequence + (even if it was already the case at the implementation level in + mach, they were named separately which could confuse people) + hm + actually, send once rights were used for important notifications + such as dead port notifications + is this still handled at the kernel level in modern ukernels ? + in viengoos, this is called the version field + see chapter 2 + + http://www.gnu.org/software/hurd/microkernel/viengoos/documentation/reference-guide.pdf + neal: btw, congratulations for viengoos, it really is a very + interesting project: ) + thanks + i don't see the point of rewriting a mach clone after reading + about it eh + I would definately do the messenger concept again + but I'd not do persistence + i don't fully understand how messengers deal with blocking + did you read chapter 4? + i read all of it but didn't understand everything :) + it's quite abstract and i didn't make time to read some of the + source code + If you have specific questions, I can try to help + i'll read those chapter again and formulate my questions after + I may have to read them as well :) + i don't understand how you manage to separate IPC from threading + actually + are messengers queues ? + messengers are super-buffers + they contain a reference to a thread object + to send a message, I use a messenger + I put the data in a buffer + and then I attach the messenger to the target messenger + braunr: my stance is that we should try to incorporate the ideas + from Viengoos into Mach in an evolutionary process... + this causes an activation to be sent to the target messenger's + thread object + neal: which activation ? + an activation is like a CPU interrupt + neal: is it "allocated" at that moment, or taken from the sending + thread ? + (i'm not sure my question really makes sense to you :/) + braunr: not sure what you are asking exactly; but the basic idea + is that the receiving process preallocates message buffers + antrik: maybe, i'm not sure + 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 + antrik is right + the traget messenger designates a memory buffer + i'm wondering about the details of this activation + is it similar to thread migration ? + just before the activation, the data is copied to the messenger's + buffer + now someone needs to be notified + (that a message arrived) + that someone is the thread designated in the target messenger's + thread field + this is done by an activation + an activation is just an upcall + a thread is forced to a particular IP + an activation isn't a "what" it's a "how" + I never understood thread migration + as it's not really about threads + nor it is about migration + neal: what happens if another message comes in before the + activation handling tread is done with the previous one?... + the messenger is enqueued on the thread object + it is delivered when the thread is in normal mode + part of delivering an activation is putting the thread is activation + mode + when in activation mode, it can't receive any activations + i see + but then, when a thread receives an activation, does it handle + several queued messengers at once (not to loose events/messages) ? + (unless it does a blocking receive on a particular messenger, which + is necessary to support memory allocation in activated mode) + it handles one at a time + ah right + it can't lose events + activations are sent per messengers/events + well, it can + but it is possible to prevent this + neal: also, is message passing completely atomic ? + I'm not sure what you mean + which part + well, all parts of a message :) + in mach, a message can contain several parts + data, rights, passing one of them may fail + only the header is atomically processed + it's not atomic in the sense that a thread can observe the data copy + that's not what i meant + is a message completely transferred or not at all in case of + failure ? + it may be partially transferred + or can it be partially transferred + ok + for instance, if the target thread doesn't provide a memory buffer + then the data can't be copied + I don't recall off hand how I dealt with bad addresses + may be it is not possible + I don't remember + sorry + but if i read the message structure correctly, there can be one + data block, and several capability addresses in a single message, right ? + yes + ok + have you considered passing only one object (either data or + capability) per message ? + or is it too inefficient ? + you at least need a reply port + s/port/messenger/ + yes but can't it be passed separately ? + then you have server state + ik + hm yes + thanks for your answers: ) + no problem -- cgit v1.2.3