[RFC] Making D-Bus suitable for being run early during boot
zeuthen at gmail.com
Fri Jul 9 14:02:32 PDT 2010
On Fri, Jul 9, 2010 at 4:50 PM, Lennart Poettering <mzqohf at 0pointer.de> wrote:
> On Fri, 09.07.10 14:36, David Zeuthen (zeuthen at gmail.com) wrote:
>> GLib's (new) D-Bus implementation (in libgio-2.0.so) would need to be
>> updated as well. It doesn't use the libdbus-1.so reference
>> implementation at all.
> Ah, I wasn't aware that you replaced the low-level parts as well.
> Are you planning to implement gdbus-daemon as well?
Nope, It doesn't really make sense to reimplement the message bus
yourself so gdbus just relies on spawning the one from the D-Bus
reference implementation if one isn't available.
(Actually, on Unix/XDG we actually currently just spawn 'dbus-launch
--autolaunch=%s --binary-syntax --close-stderr' like libdbus-1.so. I
wish the Win32 and OS X ports were that easy (they aren't, grr), we
probably should make them so and also make --autolaunch a non-private
option. I'll send some patches when I find some spare time.)
(Also, so, yeah, GDBus-using apps on Win32 / OS X will need to ship a
copy of dbus-daemon. But that's fine, they already contain their own
copy of libgio, libgobject, libglib and so on.)
>> > And 4 libs doesn't sound too bad to me. Quite doable for most
>> > distributors...
>> Typically Win32- and OS X apps bundle D-Bus implementations (and other
>> libraries such as GTK+) and we can't really retroactively update
>> those. Then there's statically linked apps which is the same. Then
>> there's the bindings and/or apps implementing the D-Bus protocol that
>> we don't even know about. Sorry, but I'm surprised that you think such
>> a change is OK.
> At least for Windows/OSX apps the abstract socket doesn't matter at
Could argue that the system bus doesn't matter at all on those
platforms... but, still, it matters for unpublished bindings and
statically-linked apps and so on. In fact, I recall Skype using an old
D-Bus version (version 0.22 or 0.23) before we broke ABI. I don't know
if Skype statically linked that old libdbus version, though. Anyway,
my point really was that we can't really make such changes in the spec
without bumping the major version number (and *everything* that
entails, e.g. co-existence with version 1, parallel socket locations
More information about the dbus