diff options
Diffstat (limited to 'microkernel')
| -rw-r--r-- | microkernel/mach/memory_object/discussion.mdwn | 13 | ||||
| -rw-r--r-- | microkernel/mach/pmap.mdwn | 74 | ||||
| -rw-r--r-- | microkernel/viengoos/documentation.mdwn | 14 | ||||
| -rw-r--r-- | microkernel/viengoos/documentation/irc_2012-02-23.mdwn | 159 |
4 files changed, 253 insertions, 7 deletions
diff --git a/microkernel/mach/memory_object/discussion.mdwn b/microkernel/mach/memory_object/discussion.mdwn index a2a1514b..907f859a 100644 --- a/microkernel/mach/memory_object/discussion.mdwn +++ b/microkernel/mach/memory_object/discussion.mdwn @@ -1,4 +1,4 @@ -[[!meta copyright="Copyright © 2011 Free Software Foundation, Inc."]] +[[!meta copyright="Copyright © 2011, 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 @@ -10,7 +10,10 @@ License|/fdl]]."]]"""]] [[!tag open_issue_documentation open_issue_gnumach]] -IRC, freenode, #hurd, 2011-08-05: +[[!toc]] + + +# IRC, freenode, #hurd, 2011-08-05 < neal> braunr: For instance, memory objects are great as they allow you to specify the mapping policy in user space. @@ -23,7 +26,8 @@ IRC, freenode, #hurd, 2011-08-05: < braunr> the kernel eviction policy :) < neal> that's an implementation detail -IRC, freenode, #hurd, 2011-09-05: + +# IRC, freenode, #hurd, 2011-09-05 <braunr> mach isn't a true modern microkernel, it handles a lot of resources, such as high level virtual memory and cpu time @@ -65,3 +69,6 @@ IRC, freenode, #hurd, 2011-09-05: pages are going to be flushed by themselves [[open_issues/resource_management_problems]]. + + +# [[open_issues/memory_object_model_vs_block-level_cache]] diff --git a/microkernel/mach/pmap.mdwn b/microkernel/mach/pmap.mdwn new file mode 100644 index 00000000..6910bfd3 --- /dev/null +++ b/microkernel/mach/pmap.mdwn @@ -0,0 +1,74 @@ +[[!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]]."]]"""]] + +[[!tag open_issue_documentation open_issue_gnumach]] + + +# IRC, freenode, #hurd, 2012-02-01 + + <sekon> on Hurd what is the difference between kernel memory object and + pmap module ?? + <sekon> pmap is heap/libraries table for each thread while kernel memory + object refers to arbitary blobs of data ?? + <braunr> sekon: pmap is the low level memory mapping module + <braunr> i.e. it programs the mmu + <braunr> and these aren't hurd-specific, they are mach modules + <sekon> braunr: so kernel memonry objects consists of a bunch of pmaps ?? + <braunr> sekon: memory objects can be various things, be specific please + <braunr> (they're certainly not a bunch of pmaps though, no) + <braunr> there is one pmap per vm_map, and there is one vm_map per task + <braunr> and there is no need for double question marks, is ther ?? + <sekon> lol then is kernel memory object , please excuse the metaphor + something like a base class for pmap + <braunr> i don't know what a "kernel memory object" is, be specific please, + again + <sekon> braunr: + http://courses.cs.vt.edu/~cs5204/fall05-gback/presentations/MachOS_Rajesh.ppt + <sekon> goto page titled External Memory Management (EMM) on page 15 + <sekon> Kernel memory object shows up + <braunr> you know there are other formats for this document + <sekon> nope .. i did not know that + <sekon> in page 17 pmamp shows up + <braunr> "the problems of external memory management" ? + <sekon> braunr: the paper i am also reading is called x15mach_thesis + <braunr> ah, that's mine + * sekon bows + <sekon> :) + <braunr> ok i see page 17 + <sekon> so please good sir explain the relationship between kernel memory + object and pmap + <sekon> (if any) + <sekon> braunr: there is no mention of kernel memory object + <braunr> again, i don't see any reference or definition of "kernel memory + object" + <sekon> but your paper says + <sekon> that when page faults occur + <sekon> the kernel contact the manager for a kernel reference object + <sekon> *memory + <braunr> where ? + <sekon> in section 2.1.3 (unless i read it wrong) + <sekon> no just a sec + <sekon> 2.1.5 + <braunr> i never used the expression "kernel memory object" there :p + <braunr> anyway, you're referring simple to memory objects as seen by + userspace pagers + <braunr> a memory object is a data container + <braunr> usually, it's a file + <braunr> but it can be anything + <braunr> the pager is the task that provides its content and implements the + object methods + <braunr> as for the relation between them and the pmap module, it's a + distant one + <braunr> i'll explain it with an example + <braunr> page fault -> request content of memory object at a given offset + with given length from pager -> ask pmap to establish the mapping in the + mmu + <sekon> braunr: thank you ver much + <sekon> *very 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 |