path: root/open_issues/dbus.mdwn
diff options
authorThomas Schwinge <>2012-01-28 15:04:40 +0100
committerThomas Schwinge <>2012-01-28 15:04:40 +0100
commit6f3a380f3c1bc602b1b86dec307abf27f71bfef4 (patch)
treea534bf34fc4d91b4d30c6f3ac4fabbc3c511201f /open_issues/dbus.mdwn
parentbe4193108513f02439a211a92fd80e0651f6721b (diff)
Diffstat (limited to 'open_issues/dbus.mdwn')
1 files changed, 82 insertions, 0 deletions
diff --git a/open_issues/dbus.mdwn b/open_issues/dbus.mdwn
new file mode 100644
index 00000000..ec39e063
--- /dev/null
+++ b/open_issues/dbus.mdwn
@@ -0,0 +1,82 @@
+[[!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
+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
+IRC, freenode, #hurd, 2011-11-26:
+ <antrik> BTW, how much effort is necessary to fix dbus?
+ <pinotree> basically, have pflocal know who's the sender
+ (pid/uid/gid/groups) in the socket send op
+IRC, freenode, #hurd, 2011-12-16:
+ <braunr> pinotree: what's the problem with dbus ?
+ <pinotree> braunr: select() returning 0 changed fd's with very short (eg <
+ 1ms) timeouts when there are actually events;
+ <pinotree> and missing socket credentials
+ <braunr> oh
+ <braunr> which socket creds interface ?
+ <pinotree> bsd, i.e. with SCM_CREDENTIALS payload for cmsg on
+ {recv,send}msg()
+ <braunr> ok
+ <braunr> SCM_RIGHTS too ?
+ <braunr> the select issue seems weird though
+ <pinotree> hm no, that's for passing fd's to other processes
+ <braunr> is it specific to pflocal or does dbus use pfinet too ?
+ <pinotree> iirc on very short timeouts the application has no time waiting
+ for the reply of servers
+ <braunr> i see
+ <pinotree> braunr:
+ <braunr> thanks
+ <pinotree> (the interesting messages are from #53 and on)
+ <braunr> 2000 eh ... :)
+ <braunr> hm i agree with neal, i don't understand why the timeout is given
+ to the kernel as part of the mach_msg call
+IRC, freenode, #hurd, 2011-12-20:
+ <braunr> hm, i don't see any occurrence of SCM_CREDENTIALS in dbus
+ <braunr> only SCM_RIGHTS
+ <pinotree> braunr: yes, that one
+ <braunr> oh
+ <braunr> i thought you said the opposite last time
+ <pinotree> dbus/dbus-sysdeps-unix.c, write_credentials_byte and
+ _dbus_read_credentials_socket (with #define HAVE_CMSGCRED)
+ <braunr> hm
+ <braunr> which version ?
+ <braunr> i don't see anything in 1.4.16
+ <pinotree> 1.4.16
+ <braunr> grmbl
+ <braunr> ah, i see
+ <braunr> SCM_CREDS
+ <pinotree> if you want, i have a simplier .c source with it
+ <braunr> no i'm just gathering info
+ <pinotree> ok
+ <braunr> what's the deal with SCM_CREDS and SCM_CREDENTIALS ?
+ <braunr> bsd vs sysv ?
+ <braunr> oh,
+ <braunr> so we actually do want both SCM_CREDS and SCM_RIGHTS for debus
+ <braunr> dbus
+ <pinotree> SCM_RIGHTS is a different matter, it is for passing fd's
+ <braunr> yes
+ <braunr> but it's used by dbus
+ <braunr> so if we can get it, it should help too
+ <pinotree> there's a preliminary patch for it done by emilio time ago, and
+ iirc it's applied to debian's glibc
+ <braunr> ah, he changed the libc
+ <braunr> right, that's the only sane way
+ <pinotree> iirc roland didn't like one or more parts of it (but i could be
+ wrong)
+ <braunr> ok