DBus on "other" platforms
René J.V. Bertin
rjvbertin at gmail.com
Thu May 12 13:59:38 UTC 2016
On Thursday May 12 2016 13:47:25 Simon McVittie wrote:
>As far as I'm aware, Apple don't install dbus by default, provide it in
>very easy to obtain and depend on. So D-Bus is clearly less "common" on
>OS X than on GNU and *BSD, and that's the OS vendor's choice, not ours.
Yes, indeed. But less common doesn't mean "fish out of the water" in my book.
>the well-known session bus, then D-Bus might still be useful for
>communication between cooperating applications (such as the KDE suite)
>on platforms where it is "uncommon".
Clearly that's the case.
>summarizes our approach to how cross-platform or otherwise we are.
Thanks. Not the most recent resource ;) but still useful.
>Please encourage the maintainers of that port, and anyone else
>maintaining D-Bus "downstream", to talk to us about getting their
>changes integrated, or at least reviewed.
OK, will do.
On Thursday May 12 2016 14:10:49 Simon McVittie wrote:
>If MacPorts' dbus integration wants to run dbus-daemon without a pid
>file, they can use --nopidfile (available since 1.6.0, which is no
>longer security-supported so I hope they aren't running that or anything
No, the port is currently at 1.10.8 .
I presume that pid files aren't necessary for daemons/agents that are started through launchctl.
>If OS X can do credentials-passing across AF_UNIX sockets, then the
>correct long-term solution is to get that implemented compatibly in
>libdbus and GDBus, and then MacPorts can stop patching libdbus to be
So we'd be looking at patching GLib and libdbus?
>has at least getpeereid(), so it should be possible to support it in
>g_socket_get_credentials(). Since it has FreeBSD ancestry (I think?) it
FreeBSD or OpenBSD, I always forget which, but yes.
>might well also be able to support G_CREDENTIALS_TYPE_FREEBSD_CMSGCRED
>(search GLib source code for __FreeBSD__, it might just be a matter of
>adding __darwin__ or something to the __FreeBSD__ #ifdefs). However,
>again, this needs to be driven by someone who runs Darwin/OS X, or it
Someone who runs OS X and has the required knowledge. It isn't very difficult to run OS X under VirtualBox nowadays, which might increase the potential population ;)
>I think I've run across this before: if I remember correctly, MacPorts
>splits up patches by the file they affect, not the logical change they
>make. If true, that's an unfortunate design decision.
I don't think that's an official design principle, but patches are indeed commonly named after the file they change.
>Setting that variable makes libdbus ignore the platform's poll()
>implementation, and emulate it inefficiently using select() instead.
>Does Darwin/OS X in fact have a broken poll() implementation, or is this
>a workaround for something?
I have no idea, the manpage just states that poll() doesn't support devices. It could well be that it's a remnant of an old patch from a previous OS that was never discarded because it still applies.
More information about the dbus