diff options
Diffstat (limited to 'open_issues/dde.mdwn')
| -rw-r--r-- | open_issues/dde.mdwn | 85 |
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 |