Floating-point and mixed-endianness in D-Bus (was: dbus mini-summit)

[Simon McVittie]

On Mon, 08 Aug 2011 at 19:21:51 +0300, Rémi Denis-Courmont wrote:
> I understand the motivation to use the native endianess if possible. But in 
> practice, I think it would be faster to just use a fixed endianess and convert 
> on the fly in the D-Bus implementations.

Implementing this in dbus-1 would be possible, but tricky; we'd have to have
an internal third endianness, "native", and use that for the message blob
in-memory. The APIs of dbus_message_get_args() and
dbus_message_iter_get_fixed_array() effectively require that arrays of fixed
types can be accessed by looking into the message blob.

After an ABI break, sure, we could just mandate that everything is in a
particular endianness, and convert immediately before/after writes/reads.

> In practice, systematic (selected at 
> build-time) conversion is probably faster than conditional (selected at run-
> time), if only because a byte swap is faster than a conditional branch.

I'm not so sure that that's true in D-Bus, where the recursive type system
means you have to do type-aware byteswapping (which requires branching
anyway, at least on the slow/byte-swapping path), but it's a good point.

> It's also simpler at the source code level.

That could well be a compelling reason to do it anyway, even if it's not a
performance gain.

> An alternative is to give-up on D-Bus over the network.

D-Bus has historically supported remote TCP acces in conjunction with shared
NFS home directories, for instance, although I must admit I'm not completely
clear on what's meant to be supported, and what happens to work by mistake.

The discussion that prompted this, though, was not actually network-related -
multiarch (as implemented in Debian/Ubuntu) isn't limited to 32- and
64-bit implementations of a related family of ABIs, it can also cope gracefully
with mixing processes from unrelated ABIs, which could have different
endianness. The most obvious example is transparent CPU emulation using
binfmt-misc and qemu-user (e.g. for an ARM(EB) or PowerPC embedded developer
mixing emulated embedded binaries with native x86), but I believe some CPU
families can even switch endianness at runtime.

> I would just leave it upon the two remaining users of PDP computers to write 
> their own interoperable implementation of D-Bus without those assumptions. 
> Presumably, they have a way to interchange octet-aligned data. Otherwise they 
> cannot connect to the Internet and are irrelevant.

I agree completely (although it'd be good to have the assumptions for libdbus
written down somewhere).

    S