Merge remote-tracking branch 'dirichlet.SCHWINGE/master'

3 files changed, 78 insertions, 77 deletions

diff --git a/community/gsoc/2013/hacklu.mdwn b/community/gsoc/2013/hacklu.mdwn
index b7de141b..d3e43dd6 100644
--- a/community/gsoc/2013/hacklu.mdwn
+++ b/community/gsoc/2013/hacklu.mdwn
@@ -1177,23 +1177,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
     <hacklu> tschwinge: ok , this doesn't affect me now. If I have time I will
       figure out it.
 
-    <teythoon> btw, what about the copyright assignment process?
-    <tschwinge> teythoon, hacklu: You still haven't heard from the FSF about
-      your copyright assignments?  What's the latest you have heard?
-    <hacklu> tschwinge: I have wrote a emali to ask for that, but no reply.
-    <teythoon> tschwinge: last and only response I got was on July 1st, the
-      last ping with explicit request for confirmation was on July the 12th
-    <tschwinge> hacklu: When did you send this email?
-    <hacklu> tschwinge: last week.
-    <tschwinge> teythoon: I suggest you send another inquiry, and please put me
-      in CC.  And if there'S no answer within a couple days (well, I'm away
-      until Monday...), I'll follow up.
-    <tschwinge> hacklu: Likewise for you; depending on when exactly ;-) you
-      sent the last email.  (Always allow for a few days until you exect an
-      answer, but if nothing happend within a week for such rather simple
-      administrative tasks, better ask again, unfrotunately.)
-    <hacklu> tschwinge:ok , I will email more
-
     <hacklu> how to understand the asyn RPC? 
     <braunr> hacklu: hm ?
     <hacklu> for instance, [hurd]/proc/main.c proc_server is loop in listening
@@ -1619,25 +1602,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
     <youpi> I'd rather let tschwinge comment on this
     <hacklu> youpi: ok :)
 
-    <youpi> how about the copyright assignments? did hacklu or teythoon receive
-      any answer?
-    <teythoon> youpi: I did, the copyright clerk told me that he finally got my
-      papers and that everything is in order now
-    <youpi> few!
-    <youpi> s/f/ph
-    <youpi> teythoon: you mean all steps are supposed to be done now, or is he
-      doing the last steps? I don't see your name in the copyright folder yet
-    <teythoon> youpi: well, he said that he had the papers and they are about
-      to be signed
-    <youpi> teythoon: ok, so it's not finished, that's why your name is not on
-      the list yet
-    <youpi> this paper stuff is really a pain
-    <hacklu> youpi: I haven't got any answer from FSF now.
-    <youpi> did you ping them recently?
-    <hacklu> I have pinged 2 week ago. 
-    <hacklu> what you mean of ping? I just write an email to him. Is it enough?
-    <youpi> yes
-
 
 # IRC, freenode, #hurd, 2013-08-12
 
@@ -1733,9 +1697,6 @@ In context of [[open_issues/libpthread/t/fix_have_kernel_resources]]:
     < hacklu> hello everyone, this is my week
       report. http://hacklu.com/blog/gsoc-weekly-report10-174/
 
-    < hacklu> btw, my FSF copyright assignment has been concepted. They guy
-      said, they have recived my mail for a while but forget to handle it.
-
     < hacklu> but now I face a new problem, when I typed the first continue
       command, gdb will continue all the breakpoint, and the inferior will run
       until normally exit.
diff --git a/community/gsoc/2013/nlightnfotis.mdwn b/community/gsoc/2013/nlightnfotis.mdwn
index a9176f51..87250c62 100644
--- a/community/gsoc/2013/nlightnfotis.mdwn
+++ b/community/gsoc/2013/nlightnfotis.mdwn
@@ -429,25 +429,6 @@ License|/fdl]]."]]"""]]
     <tschwinge> nlightnfotis: But before doing that, please do the diff first,
       so that we know (hopefully) where the erroneous build results were coming
       from.
-    <nlightnfotis> considering the Copyright assignment files, I have sent them
-      from day 1 (that is the 20th of June). I have not heard anything about
-      those documents to date (sadly)
-    <nlightnfotis> what's worst is that although I have a reference number to
-      track those documents, their (greek postal office) tracking service sucks
-      so badly, that one day it's offline, the next it suggests it can't find
-      the object in their database, the next it says it is still in the local
-      post office
-    <nlightnfotis> let me check it out now
-    <nlightnfotis> still nothing from their online service
-    <nlightnfotis> let me call them
-    <nlightnfotis> tschwinge: I called the post office regarding the copyright
-      papers. They told me that the same day (the 20th of June) it left from
-      Herakleion, Crete to Athens and the same day it must have left the
-      country heading towards the US. They also told me it takes about 1 week
-      for it to arrive.
-    <tschwinge> nlightnfotis: OK, so probably waiting at the FSF office to be
-      processed.  Let's allow for some more time.  After all, this is not
-      critical for your progress.
 
 
 # IRC, freenode, #hurd, 2013-07-10
@@ -826,25 +807,6 @@ License|/fdl]]."]]"""]]
       worker threads are actually never destroyed on debian (because of a
       debian specific patch)
 
-    <teythoon> youpi, nlightnfotis, hacklu_: btw, what about the copyright
-      assignment process
-    <tschwinge> nlightnfotis just got his on file, so there is progress.
-    <tschwinge> I have email from Donald R Robertson III
-      <copyright-clerk@fsf.org> about that -- but it is not yet present in the
-      FSF copyright.list file...
-    <tschwinge> I think I received that email because I was CCed on
-      nlightnfotis' submission.
-    <nlightnfotis> tschwinge: I have got the papers, and they were signed by
-      the FSF. They stated delivery date 11 of July, but the documents were
-      signed on the 10th of July :P
-    <tschwinge> Ah, no, I received it via hurd-maintainers@gnu.org -- and the
-      strange thing is that not all assignments that got processed got sent
-      there...
-    <tschwinge> At the recent GNU Tools Cauldron we also discussed this in the
-      GCC context; and their experience was the very same.  Emails get lost,
-      and/or take ages to be processed, etc.
-    <tschwinge> It seems the FSF is undermanned.
-
 
 # IRC, freenode, #hurd, 2013-07-27
 
@@ -3035,3 +2997,18 @@ But not the [[open_issues/libpthread_dlopen]] issue?
     <nlightnfotis> and we wanna prove that go violates this rule right? That
       the stack pointer is not pointing at the initial stack
     <braunr> yes
+
+
+# IRC, freenode, #hurd, 2013-10-09
+
+    <gnu_srs> braunr: The crash is not in the assembly code, but in the called
+      function from it:
+    <gnu_srs> pthread_sigmask (how=2, set=0xf9cac <server_block_set>,
+      oset=oset@entry=0x0) at ./pthread/pt-sigmask.c:29
+    <gnu_srs> 29        struct __pthread *self = _pthread_self ();
+    <gnu_srs> Program received signal SIGSEGV, Segmentation fault.
+    <braunr> gnu_srs: ok so, same problem as in gcc go
+    <braunr> changing the stack pointer prevents libpthread from correctly
+      fetching thread-specific data (including _pthread_self()) correctly
+    <braunr> this will be fixed when threadvards are finally replaced with true
+      tls
diff --git a/community/gsoc/project_ideas/object_lookups.mdwn b/community/gsoc/project_ideas/object_lookups.mdwn
index 88ffc633..ca586dea 100644
--- a/community/gsoc/project_ideas/object_lookups.mdwn
+++ b/community/gsoc/project_ideas/object_lookups.mdwn
@@ -69,3 +69,66 @@ In context of [[!message-id "20130918081345.GA13789@dalaran.sceen.net"]].
     <neal> braunr: That's called protected payload.
     <neal> braunr: The idea is that the kernel appends data to the message in
       flight.
+
+
+## IRC, freenode, #hurd, 2013-10-24
+
+    <teythoon> and, with some effort, getting rid of the hash table lookup by
+      letting the kernel provide the address of the object (iirc neil knew the
+      proper term for that)
+    <braunr> teythoon: that is a big interface change
+    <teythoon> how so
+    <braunr> optimizing libihash and libpthread should already be a good start
+    <braunr> well how do you intend to add this information ?
+    <braunr> ok, "big" is overstatement, but still, it's a low level interface
+      change that would probably break a lot of things
+    <teythoon> store a pointer in the port structure in gnumach, make that
+      accessible somehow
+    <braunr> yes but how ?
+    <teythoon> interesting question indeed
+    <braunr> my plan for x15 is to make this "label" part of received messages
+    <braunr> which means you need to change the format of messages
+    <braunr> that is what i call a big change
+    <teythoon> ok, so we need to provide an update path
+    <teythoon> but once done, the change to hurd will be minimal, patching
+      libports should cover most of that
+    <braunr> normally yes
+    <teythoon> so this amounts to messing with gnumach and mig and designing a
+      clever way to make the update process safe
+
+    <braunr> libihash is known to show high collision rates
+    <teythoon> right, libihash
+    <teythoon> it could use an integer hash function on the keys to distribute
+      them better
+    <braunr> i think that's already what it tries to do
+    <braunr> so merely using a better hash algorithm such as murmur should do
+      the job
+    <braunr> or use another data structure altogether
+    <teythoon> no, it does no hashing of its own on the keys
+    <braunr> are you sure ?
+    <teythoon> well, it uses only prime numbers as sizes, and computes key %
+      size
+    <braunr> well that's hashing .. :)
+    <teythoon> but this is not really a good hash
+    <braunr> yes
+    <braunr> isn't that what i said ?
+    <teythoon> right
+    <teythoon> ok, I didn't get that ;)
+    <teythoon> also, the sizes start quite small, 3, 7, 19...
+    <teythoon> and each time the hash table is grown, all items will have to be
+      updated
+    <braunr> which is why we could consider another data structure
+    <teythoon> or, for starters, to thin out that list of sizes
+    <braunr> my personal preference being radix trees
+    <teythoon> I assume you have an implementation handy?
+    <braunr> yes
+    <teythoon> cool :D
+    <braunr> but good hashing is excellent too
+    <braunr> radix trees have their own issues
+    <teythoon> braunr: http://burtleburtle.net/bob/hash/integer.html
+    <braunr> i use thomas wang's hashing function in x15
+    <braunr> or rather, my own personal c utility library, since x15 doesn't
+      hash anything currently
+    <braunr> but murmur is better
+    <braunr> we prefer distribution over hashing performances
+    <braunr> https://131002.net/siphash/