IRC.

1 files changed, 617 insertions, 0 deletions

diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn
new file mode 100644
index 00000000..d0185c60
--- /dev/null
+++ b/community/gsoc/2013/hacklu.mdwn
@@ -0,0 +1,617 @@
+[[!meta copyright="Copyright © 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]]."]]"""]]
+
+[[!toc]]
+
+
+# IRC, freenode, #hurd, 2013-06-23
+
+    <hacklu> braunr: sorry for the late reply. Honestly to say, the school
+      works had taken most of my time these days. I haven't got any
+      siginificant progress now. I am trying to write a little debugger demo on
+      Hurd.
+    <hacklu> braunr: things goes more hard than I think, these are some
+      differences between ptrace() on Hurd and Linux. I am trying to  solve
+      this.
+
+
+# IRC, freenode, #hurd, 2013-06-24
+
+    <hacklu> this is my weekly report
+      http://hacklu.com/blog/gsoc-weekly-report1-117/. 
+    <hacklu> and I have two main questions when I read the gdb source code. 
+    <hacklu> 1/What is the S_exception_raise_request()? 2/what is the role of
+      ptrace in gdb port on Hurd?
+    <youpi> hacklu: where did you see S_exception_raise_request?
+    <hacklu> in gdb/gnu-nat.c
+    <youpi> ah, in gdb
+    <hacklu> yeah. and I have read the <The hurd hacking guide>. is says the S_
+      start means server stub. 
+    <youpi> yes
+    <youpi> what happens is that gnu_wait keeps calling mach_msg
+    <youpi> to get a message
+    <youpi> then it passes that message to the various stubs servers
+    <youpi> see just below, it calls exc_server, among others
+    <youpi> and that's exc_server which ends up calling
+      S_exception_raise_request, if the message is an exception_raise request
+    <youpi> exc_server is a mere multiplexer, actually
+    <tschwinge> S_exception_raise_request is the implementation of the request
+      part (so one half of a typical RPC) of the Mach exception interface.
+    <tschwinge> See gdb/exc_request.defs in GDB and include/mach/exc.defs in
+      Mach.
+    <hacklu> youpi: how gnu_wait pass one message to exc_server?  in which
+      function?
+    <youpi> in gnu_wait()
+    <youpi> && !exc_server (&msg.hdr, &reply.hdr)
+    <hacklu> oh, I see this. 
+    <hacklu> firstly I think it is a type check simply.
+    <youpi> see the comment: "handle what we got"
+    <tschwinge> The Hurd's proc server also is involved in the exception
+      passing protocol (see its source code).
+    <hacklu> tschwinge: I will check the source code later. is the exception
+      take place in this way: 1. the inferior call ptrace(TRACE_ME). 2.the gdb
+      call task_set_exception_port. 3. mach send a notification to the
+      exception port set before. 4. gdb take some action.
+    <tschwinge> hacklu: Yes, that's it, roughly.  The idea is that GDB replaces
+      a process' standard exception port, and replaces it "with itself", so
+      that when the process that is debugged receives and exception (by Mach
+      sending a exception_raise RPC), GDB can then catch that and act
+      accordingly.
+    <tschwinge> hacklu: As for your other questions, about ptrace: As you can
+      see in [glibc]/sysdeps/mach/hurd/ptrace.c, ptrace on Hurd is simply a
+      wrapper around vm_read/write and more interfaces.
+    <tschwinge> hacklu: As the GDB port for Hurd is specific to Hurd by
+      definition, you can also directly use these calls in GDB for Hurd.
+    <tschwinge> ..., as it is currently done.
+    <hacklu> and in detail, the part 3 mach send a notification to the
+      excetption port is like this: gnu_wait get the message in mach_msg, and
+      then pass it to exc_serer by exc_server(),then exc_server call
+      S_exception_raise_request()? ?
+    <hacklu> tschwinge: yeah, I have see the ptrace.c. I was wonder about
+      nobody use ptrace in Hurd except TRACEME...
+    <tschwinge> hacklu: Right about »and in detail, [...]«.
+    <tschwinge> hacklu: It would be very good (and required for your
+      understanding anyway), if you could write up a list of things that
+      happens when a process (both under the control of GDB as well as without
+      GDB) is sent an exception (due to a breakpoint instruction, for example).
+    <tschwinge> Let me look something up.
+    <hacklu> tschwinge: what's the function of exc_server? if I can get the
+      notification in mach_msg().
+    <youpi> to multiplex the message
+    <youpi> i.e. decoding it, etc. up to calling the S_ function with the
+      proper parameters
+    <youpi> exc_server being automatically generated, that saves a lot of code
+    <tschwinge> That is generated by MIG from the gdb/exc_request.defs file.
+    <tschwinge> You'll find the generated file in the GDB build directory.
+    <hacklu> I have wrote down the filenames. after this I will check that.
+    <tschwinge> hacklu: I suggest you also have a look at the Mach 3 Kernel
+      Principles book,
+      <http://www.gnu.org/software/hurd/microkernel/mach/documentation.html>.
+    <tschwinge> This also has some explanation of the thread/task's exception
+      mechanism.
+    <tschwinge> And of course, explains the RPC mechanism, which the exception
+      mechanism is built upon.
+    <tschwinge> And then, really make a step-by-step list of what happens; this
+      should help to better visualize what's going on.
+    <hacklu> ok. later I will update this list on my blog.
+    <tschwinge> hacklu: I cannot tell off-hand why GDB on Hurd is using
+      ptrace(PTRACE_TRACEME) instead of doing these calls manually.  I will
+      have to look that up, too.
+    <hacklu> tschwinge: thanks. 
+    <tschwinge> hacklu: Anyway -- you're asking sensible questions, so it seems
+      you're making progress/are on track.  :-)
+    <hacklu> tschwinge: there is something harder than I had thought, I haven't
+      got any meaningful progress. sorry for this.
+    <tschwinge> hacklu: That is fine, and was expected.  :-)  (Also, you're
+      still busy with university.)
+    <hacklu> I will show more time and enthusiasm on this.
+    <tschwinge> hacklu: Oh, and one thing that may be confusing: as you may
+      have noticed, the names of the same RPC functions are sometimes slightly
+      different if different *.defs files.  What is important is the subsystem
+      number, such as 2400 in [GDB]/gdb/exc_request.defs (and then incremented
+      per each routine/simpleroutine/skip directive).
+    <tschwinge> hacklu: Just for completeness, [hurd]/hurd/subsystems has a
+      list of RPC subsystems we're using.
+    <tschwinge> And the name given to routine 2400, for example, is just a
+      "friendly name" that is then used locally in the code where the *.defs
+      file has been processed by MIG.
+    <tschwinge> What a clumsy explanation of mine.  But you'll get the idea, I
+      think.  ;-)
+    <tschwinge> hacklu: And don't worry about your progress -- you're making a
+      lot of progress already (even if it doesn't look like it, because you're
+      not writing code), but the time spent on understanding these complex
+      issues (such as the RPC mechanism) definitely counts as progress, too.
+    <hacklu> tschwinge: not clearly to got it as I am not sensitive with the
+      MIG's grammer. But I know, the exc is the routine 2400's alias name?
+    <tschwinge> hacklu: I'd like to have you spend enough time to understand
+      these fundamental concepts now, and then switch to "hacking mode" (write
+      code) later, instead of now writing code but not understanding the
+      concepts behind it.
+    <hacklu> I have wrote a bit code to validate my understanding when I read
+      the soruce code. But the code not run.  http://pastebin.com/r3wC5hUp
+    <tschwinge> The subsystem directive [...].  As well, let me just point you
+      to the documentation:
+      <http://www.gnu.org/software/hurd/microkernel/mach/mig/documentation.html>,
+      MIG - THE MACH INTERFACE GENERATOR, chapter 2.1 Subsystem identification.
+    <tschwinge> hacklu: Yes, writing such code for testing also is a good
+      approach.  I will have to look at that in more detail, too.
+    * tschwinge guesses hacklu is probably laughing when seeing the years these
+        documents were written in (1989, etc.).  ;-)
+    <hacklu> mach_msg make no sense in my code, and the process just hang. kill
+      -9 can't stop is either.
+    <braunr> hacklu: do you understand why kill -KILL might not work now ?
+    <hacklu> braunr: no, but I found I can use gdb to attach to that process,
+      then quit in gdb, the process quit too.
+    <hacklu> maybe that process was waiting a resume.
+    <braunr> something like that yes
+    <braunr> iirc it's related to a small design choice in the proc server
+    <braunr> something that put processes in an uninterruptible state when
+      being debugged
+    <hacklu> iirc ? 
+    <braunr> if i recall cl=orrectly
+    <braunr> correctly*
+    <hacklu> like D status in linux? 
+    <braunr> or T
+    <braunr> there has been a lot of improvements regarding signal handling in
+      linux over time so it's not really comparable now
+    <braunr> but that's the idea
+    <hacklu> in ps, i see the process STAT is THumx
+    <braunr> did you see that every process on the hurd has at least two
+      threads ?
+    <hacklu> no, but I have see that in hurd, the exception handler can't live
+      in the same context with the victim. so there must be at least two
+      threads. I think
+    <braunr> hacklu: yes
+    <braunr> that thread also handles regular signals
+    <braunr> in addition to mach exceptions
+    <braunr> (there are two levels of multiplexing in servers, first locating
+      the subsystem, then the server function)
+    <braunr> hacklu: if what i wrote is confusing, don't hesitate to ask for
+      clarifications (i really don't intend to make things confusing)
+    <hacklu> braunr: I don't know what you say about the "multiplexing in
+      servers". For instance, is it means how to pass message from  mach_msg to
+      exc_server in gnu_wait()?
+    <braunr> hacklu: i said that the "message thread" handles both mach
+      exceptions and unix signals
+    <braunr> hacklu: these are two different interfaces (and in mach terms,
+      subsystems)
+    <braunr> hacklu: see hurd/msg.defs for the msg interface (which handles
+      unix signals)
+    <braunr> hacklu: to handle multiple interfaces in the same thread, servers
+      need to first find the right subsystem
+    <braunr> this is done by subsequently calling all demux functions until one
+      returns true
+    <braunr> (finding the right server function is done by these demux
+      functions)
+    <braunr> hacklu: see hurd/msgportdemux.c in glibc to see how it's done
+      there
+    <braunr> it's short actually, i'll past it here :
+    <braunr>   return (_S_exc_server (inp, outp) ||
+    <braunr>           _S_msg_server (inp, outp));
+    <braunr> hacklu: did that help ?
+    <hacklu> braunr: a bit more confusing. one "message thread" handles
+      exceptions and signals, means the message thread need to recive message
+      from two port. then pass the message to the right server which handle the
+      message. the server also should pick the right subsystem from a lot of
+      subsystems to handle the msg. is this ? 
+    <braunr> the message thread is a server thread
+    <braunr> (which means every normal process is actually also a server,
+      receiving exceptions and signals)
+    <braunr> there may be only two ports, or more, it doesn't matter much, the
+      port set abstraction takes care of that
+    <hacklu> so the message thread directly pass the msg to the right
+      subsystem?
+    <braunr> not directly as you can see
+    <braunr> it tries them all until one is able to handle the incoming message
+    <braunr> i'm not sure it will help you with gdb, but it's important to
+      understand for a better general understanding of the system
+    <braunr> ugly sentence
+    <hacklu> ah, I see. like this in gnu-nat.c  if(!notify_server(&msg.hdr,
+      &reply.hdr) && !exc_server(&msg.hdr...) 
+    <braunr> yes
+    <hacklu> the thread just ask one by one.
+    <braunr> be careful about the wording
+    <braunr> the thread doesn't "send requests"
+    <braunr> it runs functions
+    <braunr> (one might be tempted to think there are other worker threads
+      waiting for a "main thread" to handle demultiplexing messages)
+    <hacklu> I got it.
+    <hacklu> the notify_server function is just run in the same context in
+      "message thread",and there is no RPC here. 
+    <braunr> yes
+    <hacklu> and the notify_server code is generater by mig automatically.
+    <braunr> yes
+
+
+# IRC, freenode, #hurd, 2013-06-29
+
+[[!tag open_issue_documentation]]
+
+    <hacklu> I just failed to build the demo on
+      this. http://walfield.org/pub/people/neal/papers/hurd-misc/ipc-hello.c
+    <hacklu> or, example in machsys.doc called simp_ipc.c
+    <pinotree> we don't use cthreads anymore, but pthreads
+    <hacklu> pinotree: em.. and I also failed to find the <servers/env_mgr.h>
+      in example of <A programmer's guide to MACH system call>
+    <pinotree> that i don't know
+    <hacklu> maybe the code in that book out-of-date
+    <teythoon> hacklu: mig and mach ipc documentation is quite dated
+      unfortunately, and so are many examples floating around the net
+
+    <hacklu> btw, I have one more question. when I read <Mach 3 kernel
+      interface>. I find this state: When an exception occurs in a thread, the
+      thread sends an exception message to
+    <hacklu> its exception port, blocking in the kernel waiting for the receipt
+      of a reply. It is
+    <hacklu> assumed that some task is listening to this
+    <hacklu> port, using the  exc_serverfunction to decode the messages and
+      then call the
+    <hacklu> linked in  catch_exception_raise. It is the job of
+      catch_exception_raiseto handle the exception and decide the course of
+      action for thread.
+    <hacklu> that says, it assumed another task to recieve the msg send to one
+      thread's exception port. why another task? 
+    <hacklu> I remmebered, there are at least two threads in one task, one is
+      handle the exception stuffs.
+    <braunr> there are various reasons
+    <braunr> first is, the thread causing the exception is usually not waiting
+      for a message
+    <braunr> next, it probably doesn't have all the info needed to resolve the
+      exception
+    <braunr> (depending on the system design)
+    <braunr> and yes, the second thread in every hurd process is the msg
+      thread, handling both mach exceptions and hurd signals
+    <hacklu> but in this state, I can't find any thing with the so called msg
+      thread
+    <braunr> ?
+    <hacklu> if exist a task to do the work, why we need this thread?
+    <braunr> this thread is the "task"
+    <hacklu> ?
+    <braunr> the msg thread is the thread handling exceptions for the other
+      threads in one task
+    <braunr> wording is important here
+    <braunr> a task is a collection of resources
+    <braunr> so i'm only talking about threads really
+    <braunr> 14:11 < hacklu> assumed that some task is listening to this
+    <braunr> this is wrong
+    <braunr> a task can't listen
+    <braunr> only a thread can
+    <hacklu> in you words, the two thread is in the same task?
+    <braunr> yes
+    <braunr> 14:32 < braunr> and yes, the second thread in every hurd process
+      is the msg thread, handling both mach exceptions and hurd signals
+    <braunr> process == task here
+    <hacklu> yeah, I always think the two thread stay in one task. but I found
+      that state in <mach 3 kernel interface>. so I confuzed
+    <hacklu> s/confuzed/confused
+    <braunr> statement you mean
+    <hacklu> if two thread stay in the same task. and the main thread throw a
+      exception, the other thread to handle it?
+    <braunr> depends on how it's configured
+    <braunr> the thread receiving the exceptions might not be in the same task
+      at all
+    <braunr> on the hurd, only the second thread of a task receives exception
+    <braunr> s
+    <hacklu> I just wonder how can the second thread catch the exception from
+      its containning task
+    <braunr> forget about tasks
+    <braunr> tasks are resource containers
+    <braunr> they don't generate or catch exceptions
+    <braunr> only threads do
+    <braunr> for each thread, there is an exception port
+    <braunr> that is, one receive right, and potentially many send rights
+    <braunr> the kernel uses a send right to send exceptions
+    <braunr> the msg thread waits for messages on the receive right
+    <braunr> that's all
+    <hacklu> ok. if I divide zero in main thread, the kernel will send a msg to
+      the main thread's exception port. and then, the second thread(in the same
+      task) is waiting on that port. so he get the msg. is it right?
+    <braunr> don't focus on main versus msg thread
+    <braunr> it applies to all other threads
+    <braunr> as well
+    <braunr> otherwise, you're right
+    <hacklu> ok, just s/main/first
+    <braunr> no
+    <braunr> main *and* all others except msg
+    <hacklu> main *and* all others except msg ?
+    <braunr> the msg thread gets exception messages for all other threads in
+      its task
+    <braunr> (at least, that's how the hurd configures things)
+    <hacklu> got it.
+    <hacklu> if the msg thread throw exception either, who server for himself?
+    <braunr> i'm not sure but i guess it's simply forbidden
+    <hacklu> i used gdb to attach a little progrom which just contains a divide
+      zero. and I only found the msg thread is in the glibc.  
+    <braunr> yes
+    <hacklu> where is the msg thread located in. 
+    <braunr> it's created by glibc
+    <hacklu> is it glibc/hurd/catch-exc.c?
+    <braunr> that's the exception handling code, yes
+    <hacklu> there are some differences between the code and the state in <mach
+      3 system interface>.
+    <braunr> state or statement ?
+    <hacklu> staement
+    <braunr> which one ?
+    <hacklu> http://pastebin.com/ZTBrUAsV
+        When an exception occurs in a thread, the thread sends an exception
+          message to
+        its exception port, blocking in the kernel waiting for the receipt of a
+          reply. It is
+        assumed that some task is listening (most likely with mach_msg_server)
+          to this
+        port, using the  exc_serverfunction to decode the messages and then
+          call the
+        linked in  catch_exception_raise. It is the job of
+          catch_exception_raiseto handle the exception and decide the course of
+          action for  thread. The state of the
+        blocked thread can be examined with thread_get_state.
+    <braunr> what difference ?
+    <hacklu> in the code, I can't find things like exc_server,mach_msg_server
+    <braunr> uh
+    <braunr> ok it's a little tangled
+    <braunr> but not that much
+    <braunr> you found the exception handling code, and now you're looking for
+      what calls it
+    <braunr> simple
+    <braunr> see _hurdsig_fault_init
+    <hacklu> from that statemnet I thought there are another _task_ do the
+      exception things for all of the systems thread before you have told me
+      the task means the msg thread.
+    <braunr> again
+    <braunr> 14:47 < braunr> forget about tasks
+    <braunr> 14:47 < braunr> tasks are resource containers
+    <braunr> 14:47 < braunr> they don't generate or catch exceptions
+    <braunr> 14:47 < braunr> only threads do
+    <hacklu> yeah, I think that document need update.
+    <braunr> no
+    <braunr> it's a common misnomer
+    <braunr> once you're used to mach concepts, the statement is obvious
+    <hacklu> braunr: so I need read more :)
+    <hacklu> _hurdsig_fault_init send exceptions for the signal thread to the
+      proc server?
+    <hacklu> why come about _proc_ server?
+    <braunr> no it gives the proc server a send right for signals
+    <braunr> exceptions are a mach thing, signals are a hurd thing
+    <braunr> the important part is
+    <braunr>   err = __thread_set_special_port (_hurd_msgport_thread,
+    <braunr>                                    THREAD_EXCEPTION_PORT, sigexc);
+    <hacklu> this one set the exception port?
+    <braunr> yes
+    <braunr> hm wait
+    <braunr> actually no, wrong part :)
+    <braunr> this sets the excpetion port for the msg thread (which i will call
+      the signal thread as mentioned in glibc)
+    <hacklu> but the comment above this line, Direct signal thread exceptions
+      to the proc server  means what?
+    <braunr> that the proc server handles exceptions on the signal thread
+    <hacklu> the term signal thread equals the term msg thread?
+    <braunr> yes
+    <hacklu> so, the proc server handles the exceptions throwed by the msg
+      thread?
+    <braunr> looks that way
+    <hacklu> feels a little strange.
+    <braunr> why ?
+    <braunr> this thread isn't supposed to cause exceptions
+    <braunr> if it does, something is deeply wrong, and something must clean
+      that task up
+    <braunr> and the proc server seems to be the most appropriate place from
+      where to do it
+    <hacklu> why need a special server to just work the msg thread? I don't
+      think that thread will throw exception frequentlly
+    <braunr> what does frequency have to do with anything here ?
+    <braunr> ok the appropriate code is _hurdsig_init
+    <braunr> the port for receiving exceptions is _hurd_msgport
+    <braunr> the body of the signal thread is _hurd_msgport_receive
+    <hacklu> aha, in the _hurd_msgport_receive I have finally found the
+      while(1) loop mach_msg_server().
+    <hacklu> so the code is conform with the documents. 
+    <hacklu> braunr: [21:18] <braunr> what does frequency have to do with
+      anything here ? yes, I have totally understood your words now. thank you
+      very much.
+    <braunr> :)
+
+
+# IRC, freenode, #hurd, 2013-07-01
+
+    <hacklu> hi. this is my weekly
+      report. http://hacklu.com/blog/gsoc-weekly-report2-124/ welcome to any
+      comment
+    <hacklu> teythoon: I only get clear about the rpc stuff. seems a lot behind
+      my plan 
+    <youpi> good progress :)
+    <hacklu> I have wrote the details of the exception handle which was asked
+      by tschwing_ last week. Am I all right in my post?
+    <youpi> hacklu: as far as I understand signals, yes :)
+    <hacklu> youpi: thanks for god, I am on the right way finally... :)
+    <hacklu> the mig book says simpleroutine is the one use to implement asyn
+      RPCs which doesn't expect an reply. But I have found a place to pass an
+      reply port to the RPC interface which has been declared as simpleroutine
+    <youpi> hacklu: probably the simpleroutine hardcodes a reply port?
+
+    <youpi> hacklu: about _hurd_internal_post_signal, this is the hairiest part
+      of GNU/Hurd, signal handling
+    <youpi> simply because it's the hairiest part of POSIX :)
+    <youpi> you probably want to just understand that it implements the
+      POSIXity of signal delivering
+    <youpi> i.e. deliver/kill/suspend the process as appropriate
+    <youpi> I don't think you'll need to dive more
+    <hacklu> aha. 
+    <hacklu> it will save a lot of time.
+    <hacklu> it seems like the wait_for_inferior() in gdb. which also has too
+      many lines and too many goto
+    <youpi> hacklu: btw, which simpleroutine were you talking  about ?
+    <hacklu> I forget where it is, I am finding it now.
+    <youpi> which version of gdb are you looking the source of?
+    <youpi> (in mine, wait_for_inferior is only 45 lines long)
+    <hacklu> I dont know how to pick the verison, I just use the git
+      version. maybe I give a wrong name.
+    <youpi> ok
+    <hacklu> youpi:I remembered, my experience comes from here
+      http://www.aosabook.org/en/gdb.html. (All of this activity is managed by
+      wait_for_inferior. Originally this was a simple loop, waiting for the
+      target to stop and then deciding what to do about it, but as ports to
+      various systems needed special handling, it grew to a thousand lines,
+      with goto statements criss-crossing it for poorly understood 
+    <hacklu> reasons.)
+    <hacklu> youpi: the simpleroutine is gdb/gdb/exc_request.defs
+    <youpi> so there is indeed an explicit reply port
+    <hacklu> but simpleroutine is for no-reply use. why use reply port here?
+    <youpi> AIUI, it's simply a way to make the request asynchronous, but still
+      permit an answer
+    <hacklu> ok, I will read the mig book carefully.
+    <braunr> hacklu: as youpi says
+    <braunr> a routine can be broken into two simpleroutines
+    <braunr> that's why some interfaces have interface.defs,
+      interface_request.defs and interface_reply.defs files
+    <braunr> nlightnfotis: in mach terminology, a right *is* a capability
+    <braunr> the only thing mach doesn't easily provide is a way to revoke them
+      individually
+    <nlightnfotis> braunr: Right. And ports are associated with the process
+      server and the kernel right? I mean, from what I have understood, if a
+      process wants to send a signal to another one, it has to do so via the
+      ports to that process held by the process server
+    <nlightnfotis> and it has to establish its identity before doing so, so
+      that it can be checked if it has the right to send to that port.
+    <braunr> yes
+    <nlightnfotis> do process own any ports? or are all their ports associated
+      with the process server?
+    <nlightnfotis> *processes
+    <braunr> mach ports were intended for a lot of different uses
+    <braunr> but in the hurd, they mostly act as object references
+    <braunr> the process owning the receive right (one at most per port)
+      implements the object
+    <braunr> processes owning send rights invoke methods on the object
+    <braunr> use portinfo to find out about the rights in a task
+    <braunr> (process is the unix terminology, task is the mach terminologyà
+    <braunr> )
+    <braunr> i use them almost interchangeably
+    <nlightnfotis> ahh yes, I remember about the last bit. And mach tasks have
+      a 1 to 1 association with user level processes (the ones associated with
+      the process server)
+    <braunr> the proc server is a bit special because it has to know about all
+      processes
+    <braunr> yes
+
+In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
+
+    <braunr> hacklu: if you ever find out about either glibc or the proc server
+      creating one receive right for each thread, please let me know
+
+
+# IRC, freenode, #hurd, 2013-07-07
+
+    <hacklu> how fork() goes? 
+    <pinotree> see sysdeps/mach/hurd/fork.c in glibc' sources
+    <hacklu> when the father has two thread( main thread and the signal thead),
+      if the father call fork, then the child inmediatelly call exev() to
+      change the excute file. how many thread in the children?
+    <hacklu> For instance, the new execute file also have two thread. 
+    <hacklu> will the exev() destroyed two threads and then create two new?
+    <hacklu> s/exev()/excv()
+    <hacklu> s/exev()/exec() :)
+
+    <hacklu> what libhurduser-2.13.so does?
+    <hacklu> where can I find this source?
+    <pinotree> contains all the client stubs for hurd-specific RPCs
+    <pinotree> it is generated and built automatically within the glibc build
+      process
+
+    <hacklu> and what is the "proc" server?
+    <pinotree> what handles in user spaces the processes
+    <hacklu> so if  I call proc_wait_request(),  I will go into the
+      S_proc_wait_reply?
+    <hacklu> thanks, I have found that. 
+
+
+# IRC, freenode, #hurd, 2013-07-08
+
+    <hacklu> hi, this is my weekly
+      report. http://hacklu.com/blog/gsoc-weekly-report3-137/
+    <hacklu> this week I have met a lot of obstacles. And I am quite desired to
+      participate in this meeting.
+    <tschwinge> hacklu: So from your report, the short version is: you've been
+      able to figure out how the things work that you were looking at (good!),
+      and now there are some new open questions that you're working on now.
+    <tschwinge> hacklu: That sounds good.  We can of course try to help with
+      your open questions, if you're stuck figuring them out on your own.
+    <hacklu> tschwinge: the most question is: what is the proc server? why need
+      to call proc_get_reqeust() before the mach_msg()?
+    <hacklu> and Is there exist any specific running sequence between father
+      and child task after fork()? And I found the inferior always call the
+      trace_me() in the same time(the trace me printf always in the same line
+      of the output log). which I have post in my report. 
+    <tschwinge> hacklu: The fork man-page can provide a high-level answer to
+      your Q3: »The child process is created with a single thread—the one that
+      called fork().  The entire virtual address space of the parent is
+      replicated in the child, including the states of mutexes, condition
+      variables, and other pthreads objects [...]«
+    <tschwinge> hacklu: What happens in GNU Hurd is that the signal thread is
+      also "cloned" (additionally to the thread which called fork), but then it
+      (the signal thread) is re-started from the beginning.  (So this is very
+      much equivalent to creating a new signal thread.)
+    <tschwinge> hacklu: Then, upon exec, a new memory image is created/loaded,
+      replacing the previous one.  [glibc]/sysdeps/mach/hurd/execve.c.  What
+      actually happens with the existing thread (in particular, the signal
+      thread) I don't know off-hand.  Then answer is probably found in
+      [glibc]/hurd/hurdexec.c -- and perhaps some code of the exec server
+      ([hurd]/exec/).
+    <hacklu> I have checked the status of my regiter mail to FSF. it says it
+      had arrived in USA. 
+    <tschwinge> hacklu: OK, good.
+    <tschwinge> hacklu: This is some basic information about the observer_*
+      functions is GDB:
+      http://sourceware.org/gdb/current/onlinedocs/gdbint/Algorithms.html#index-notifications-about-changes-in-internals-57
+      »3.10 Observing changes in gdb internals«.
+    <hacklu> tschwinge: not too clear. I will think this latter. and what is
+      the proc server?
+    <teythoon> hacklu: /hurd/proc, maps unix processes to mach threads afaiui
+    <hacklu> teythoon: question is, the mach_msg() will never return unless I
+      called proc_wait_request() first.
+    <teythoon> hacklu: sorry, I've no idea ;)
+    <hacklu> teythoon: :)
+    <tschwinge> hacklu: I will have to look into that myself, too; don't know
+      the answer off-hand.
+    <tschwinge> hacklu: In your blog you write proc_get_request -- but such a
+      functions doesn't seems to exist?
+    <hacklu> tschwinge: s/proc_get_request/proc_wait_request  called in
+      gun_wait() [gnu-nat.c]
+    <tschwinge> hacklu: Perhaps the wait man-page's description of WUNTRACED
+      gives a clue: »also return if a child has stopped [...]«.  But it also to
+      me is not yet clear, how this relates to the mach_mag call, and how the
+      proc server exactly is involved in it.
+    <tschwinge> I'm reading various source code files.
+    <tschwinge> At least, I don't undestand why it is required for an exception
+      to be forwarded.
+    <hacklu> if I need to read the proc server source code?
+    <tschwinge> I can see how it to become relevant for the case that GDB has
+      to be informed that the debugee has exited normally.
+    <tschwinge> hacklu: Yeah, probably you should spend some time with that, as
+      it will likely help to get a clearer picture of the situation, and is
+      relevant for other interactions in GDB, too.
+    <tschwinge> hacklu: By the way, if you find that pieces of the GDB source
+      code (especially the Hurd files of it) are insufficiently documented,
+      it's a very good idea, once you have figured out something, to add more
+      source code comments to the existing code.  Or writed these down
+      separately, if that is easier.
+    <hacklu> which is the proc server? hurd/exec ?
+    <hacklu> that ok, I already comment things on my notes. 
+    <tschwinge> hacklu: [Hurd]/proc/
+    <tschwinge> hacklu: And [Hurd]/hurd/process*.defs
+    <hacklu> got it
+    <tschwinge> hacklu: I'll have to experiment a bit with your HDebugger
+      example, but I'm out of time right now, sorry.  Will continue later.
+    <hacklu> tschwinge: yep, the HDebugger has a problem, if you put the
+      sleep() after the printf in the just_print(), thing will hang. 
+    <hacklu> tschwinge: and I am a little curious about how do you find my
+      code? I dont't remember I have mentioned that :)
+    <hacklu> tschwinge: I have post my gihub link in the last week report, I
+      found that.
+    <tschwinge> hacklu: That's how I found it, yes.
+    <hacklu> tschwinge: :)