DBus for LSB

Robert Schweikert rjschwei at suse.com
Wed Apr 18 07:31:22 PDT 2012

On 04/18/2012 06:37 AM, Simon McVittie wrote:
> On 17/04/12 19:08, Colin Walters wrote:
>> 1) The wire protocol
> This has effectively been "add-only" for a while.

Thus this sounds like a great candidate for the LSB, but what is "the 
wire protocol" and what are the interfaces? LSB is primarily and ABI 
>> 2) The libdbus-1.so shared library
> (More precisely, libdbus-1.so.3, since LSB standardizes a particular
> SONAME, as I understand it - and if it doesn't, it should.)

Yes, we would specify the full name, libdbus-1.so.3 if that is the 
object that goes along with version 1.4 of DBus.

> Can we say that the portable interface is that you must use it from your
> main thread, and only your main thread?

There is nothing in the LSB that prescribes that libraries must be 
thread safe. Thus, this is not an issue.

> The current situation is that
> libdbus sort of works with threads, sometimes, but not reliably.
> (1.5 is better, but probably still not perfect.)
> Attempting to cope with both multi-threading and malloc() returning NULL
> is a major impediment to libdbus - either/or would be fine, but having
> both is a problem.
>> 3) The interface and semantics exported by the bus daemon
> These are mostly add-only, with a few exceptions (e.g. changing the
> behaviour of eavesdropping).
> Can we say that the LSB behaviour does not guarantee anything about
> eavesdropping?

Similar to thread safety, the LSB makes not guarantees about the 
"security" of included interfaces/libraries. Thus being able to 
eavesdrop does not have any effect on inclusion in LSB or the LSB 
specification itself.


Robert Schweikert                           MAY THE SOURCE BE WITH YOU
SUSE-IBM Software Integration Center                   LINUX
Tech Lead
rjschwei at suse.com
rschweik at ca.ibm.com

More information about the dbus mailing list