IRC.

1 files changed, 72 insertions, 13 deletions

diff --git a/open_issues/dde.mdwn b/open_issues/dde.mdwn
index 5f6fcf6a..b25e53d7 100644
--- a/open_issues/dde.mdwn
+++ b/open_issues/dde.mdwn
@@ -33,7 +33,7 @@ The plan is to use [[libstore_parted]] for accessing partitions.
 
 ## IRC, freenode, #hurd, 2012-02-08
 
-At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
+After the microkernel devroom at [[community/meetings/FOSDEM_2012]]:
 
     <antrik> there was quite some talk about DDE. I learnt that there are newer
       versions in Genode and in Minix (as opposed to the DROPS one we are
@@ -109,6 +109,40 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
       you want. It uses Linux 2.6.26 usb subsystem.
 
 
+## IRC, freenode, #hurd, 2013-02-15
+
+After the microkernel devroom at [[community/meetings/FOSDEM_2013]].
+
+    <pinotree> youpi: speaking of dde, was there any will among other
+      microkernel os developers to eventually develop one single dde (with
+      every team handling the custom glue of the own kernel)?
+    <youpi> well, there is still upstream dde actually
+    <youpi> in dresden
+    <youpi> nothing was really decided or anything (it was a round table, not a
+      workgroup)
+    <youpi> but conversation converged into sharing the DDE maintenance, yes
+    <youpi> and dresden would be the logical central place
+    <youpi> pb is that they don't have the habit of being very open
+    <youpi> http://svn.tudos.org/repos/oc/tudos/trunk/l4/pkg/dde  has a recent
+      enough version
+    <youpi> which macsim confirmed having all the latest commits from the
+      internal repository
+    <pinotree> i see
+    <youpi> so it seems a viable solution on the medium term
+    <youpi> the long term might need a real visible open source project
+    <youpi> but we should probably still keep basing on dresden work
+    <youpi> (better take work being done anywhere)
+    <pinotree> well, if the upstream is not really open, microkernel teams
+      could just fork it and all work on it
+    <youpi> that's what I mean
+    <pinotree> should still be a win than everybody maintaining their own dde
+    <youpi> sure
+    <pinotree> ah yes, i was writing and i'm slow at it :)
+    <youpi> but at least we can try to work with dresden
+    <youpi> see how open they could become by just asking :)
+    <pinotree> right
+
+
 # IRC, OFTC, #debian-hurd, 2012-02-15
 
     <pinotree> i have no idea how the dde system works
@@ -484,26 +518,17 @@ At the microkernel davroom at [[community/meetings/FOSDEM_2012]]:
     <braunr> *sigh*
 
 
-
-# IRC, freenode, #hurd, 2012-08-18
+## IRC, freenode, #hurd, 2012-08-18
 
     <braunr> hum, leaks and potential deadlocks in libddekit/thread.c :/
 
 
-# IRC, freenode, #hurd, 2012-08-18
+## IRC, freenode, #hurd, 2012-08-18
 
     <braunr> nice, dde relies on a race to start ..
 
 
-# IRC, freenode, #hurd, 2012-08-18
-
-    <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
-      cleanly, and we can't attach another netdde instance
-
-[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
-
-
-# IRC, freenode, #hurd, 2012-08-21
+## IRC, freenode, #hurd, 2012-08-21
 
 In context of [[libpthread]].
 
@@ -513,6 +538,40 @@ In context of [[libpthread]].
     <braunr> either in netdde or pfinet
 
 
+## IRC, freenode, #hurd, 2013-02-28
+
+    <braunr> (which needs the same kinds of fixes that libpthread got)
+    <braunr> actually i'm not sure why he didn't simply reuse the pthread
+      functions :/
+    <youpi> which kind of fixes?
+    <youpi> cancellation?
+    <braunr> timeouts
+    <braunr> cancellation too but that's less an issue
+    <youpi> I'm not sure it really needs timeout work
+    <youpi> on what RPC?
+    <youpi> pfinet is just using the mach interface
+    <braunr> i don't know but it clearly copies some of the previous pthread
+      code from pthread_cond_timedwait
+    <braunr> see libddekit/thread.c:_sem_timedwait_internal
+    <youpi> I recognize the comment indeed :)
+    <youpi> I guess he thought he might need some particular semantic that
+      libpthread may not provide
+    <braunr> also, now that i think about it, he couldn't have used libpthread,
+      could he ?
+    <braunr> and there was no condition_timedwait in cthreads
+    <braunr> there is a deadlock in netdde
+    <braunr> it occurs sometimes, at high network speeds
+    <braunr> (well high, 4 MiB/s or more)
+
+
+# IRC, freenode, #hurd, 2012-08-18
+
+    <braunr> hm looks like if netdde crashes, the kernel doesn't handle it
+      cleanly, and we can't attach another netdde instance
+
+[[!message-id "877gu8klq3.fsf@kepler.schwinge.homeip.net"]]
+
+
 # DDE for Filesystems
 
 ## IRC, freenode, #hurd, 2012-10-07